Some weeks ago my son who works for one of the iconic software companies rang up and asked, "What is the definition of Standard Deviation?"
I was rather taken aback. He has a good degree in Mathematics and his college days are not all that long ago - at least compared to mine. So was it a trick question? Since at the moment I was having lunch, I used that as an excuse to get back later with the answer.
When I did get back with the definition (without having had to google it :-), I got the full story.
He was going through some code where the comments described a wrong computation for Standard Deviation. Yet, given the halo around the people who generated the code he doubted his own understanding. As it turned out the code was correct. The comments were wrong.
Imagine if a maintainer decided to change the code in accordance with the comment.
Here are the mistakes made by the author of the comments:
Describe the WHAT. In this case it is sufficient to say, "The following computes the Standard deviation of ....". If required a reference to a standard text or a Wikipedia link can be provided.
Describe the WHY? What use is going to be made of the Standard Deviation? Why is it required to be computed?
The HOW should be in the form of an algorithm. Again, in many cases the algorithm would be available in standard texts, or in Wikipedia; provide a link.
And use Intentional Naming. Use StdDev, or Sigma; not S.
05 June 2011
16 May 2011
Code Reviews
Seth Godin has a recent post which I think is applicable to software artifacts.
Code and documentation will be required to be understood by developers long after the original authors have gone. It is important that reviewers "share their confusions" rather than "improving" the code.
Code and documentation will be required to be understood by developers long after the original authors have gone. It is important that reviewers "share their confusions" rather than "improving" the code.
14 April 2011
Are Business Models, Values Not Tested?
In a post made some months back, Seth Godin talks of the culture of testing at Netflix. According to Seth, Netflix tests everything, except for three things: their business model, their culture, and the change in business model by switching from postal delivery to online delivery. According to Seth these could not be tested.
Is it really true that these cannot be tested?
It is true that these cannot be tested like DVD cases. (Netflix tested 200 of those before deciding on the design.) Yes, they cannot be tested in-house, on a test-bench. But they are tested - and have to be tested - in the market place. Values too are a result of testing in the market place of life. And like all testing these too involve time and costs.
All start-ups are based on memes that the founders bring with them. Values are memes. Business models too are memes. Memes like genes, are subject to Darwinian testing.
Netflix's early story gives an idea of the memes that led to the initial business model.
It is, I think, safe to assume that Netflix's values are largely based on what the founders had experienced, and seen, and absorbed, at other companies. These were the result of "testing" in their earlier work life. It is also safe to assume that these values are put to the test every day at Netflix. If the values are practiced they are reinforced, otherwise they mutate, or die.
Is it really true that these cannot be tested?
It is true that these cannot be tested like DVD cases. (Netflix tested 200 of those before deciding on the design.) Yes, they cannot be tested in-house, on a test-bench. But they are tested - and have to be tested - in the market place. Values too are a result of testing in the market place of life. And like all testing these too involve time and costs.
All start-ups are based on memes that the founders bring with them. Values are memes. Business models too are memes. Memes like genes, are subject to Darwinian testing.
Netflix's early story gives an idea of the memes that led to the initial business model.
It is, I think, safe to assume that Netflix's values are largely based on what the founders had experienced, and seen, and absorbed, at other companies. These were the result of "testing" in their earlier work life. It is also safe to assume that these values are put to the test every day at Netflix. If the values are practiced they are reinforced, otherwise they mutate, or die.
10 April 2011
The Facebook Effect: Some Lessons for Startups
Note: The page numbers mentioned below are for the Virgin Books edition available here in India.
Innovation
Facebook was certainly not the first social networking site. There was (and still is) Orkut. There was Friendster. There was (and still is) MySpace. It definitely was not technology.
I believe the key component of the innovation was to spot a social need of students at Harvard. A need that was not addressed by other social sites. The other components of the innovation were:
Open Source
Development could be done from a college dorm because open source platforms were used. The major cost was the cost of servers. I suspect Facebook continues to use open source platforms. No point building revenues for Oracle and Microsoft:-) Microsoft did at one time offer to buy Facebook. If that would have happened, I suppose they would have switched to Windows Server.
Lesson: FOSS provides a good platform for entrepreneurs. But be aware, that, "... while the software might have been free, it was not simple to operate." (pg38). Software wallahs wanting to use FOSS must be ready to invest time, or have already invested time, in learning the internals of the tools. It is an investment worth making.
Vision & Values
At one stage someone proposed to introduce an additional mouse click so that an additional ad could be shown. This was not acceptable to Zuckerberg as he was "fanatically devoted to making his service easy to use". Throughout the book there are numerous such examples. Though advertisers provide revenue, it is the users and their links that are the real assets of Facebook.
Lesson: Revenue, like costs, are constraints, they should not be the objective function.
Sustainable Growth
Pg 57-58:
"Every time the database was upgraded or the server array reconfigured, Zuckerberg tried to do it in a way that could accommodate ten times more users than TheFacebook had at that moment."
And again:
"So if the systems were acting up, capacity was at the max,or they couldn't yet afford new servers, they'd simply wait before launching at the next school. This was a rare asset at an underfinanced Web start-up. It allowed TheFacebook to grow methodically ..."
Lesson: Uncontrolled growth is a cancer. It can kill. Never let growth destroy the quality of the customer experience.
Growing after Assuring Demand
Pg 140: "By keeping the gates closed and only opening at schools once there was proven demand, Zuckerberg and Moskovitz, the expansion guru, ensured that when TheFacebook did open, usage would explode."
Lesson: Test your hypotheses about the market.
Not Cool
Being cool can get early adopters. But for Crossing the Chasm,
and then to get Inside the Tornado
, and then to become a platform, you need to be perceived differently, and do things differently. And all along you need to consistently evolve your vision. The book is a study in how Zuckerberg did it.
Work Place Silence
Pg 49: "When they sat at their laptops .... it was eerily quiet. That is because when they did talk to one another, they did over instant messaging, even when they were sitting next to one another." (emphasis is mine)
Again:
Pg 137: "One employee a few years older who sat about six feet from Zuckerberg in those days received an IM from the boss. "Hey," it read. It was the first time he had gotten such a message. So, seeking to be convivial, this guy stood up from his chair, turned to Zuckerberg, and said out loud in a friendly voice "Hey!" Zuckerberg continued staring blankly at his screen."
Comment: The workplace atmosphere should be that of a good college library. Not that of a canteen. This is more so for start-ups as they should not be spending money on private offices.
And Finally
Learn how to leverage social media for marketing your offering.
Innovation
Facebook was certainly not the first social networking site. There was (and still is) Orkut. There was Friendster. There was (and still is) MySpace. It definitely was not technology.
I believe the key component of the innovation was to spot a social need of students at Harvard. A need that was not addressed by other social sites. The other components of the innovation were:
- Identity had to be true. You had to be who you said you were. This was validated by the college email-id.
- It had nothing to do with meeting people. You online network was the same as your off-line network.
Open Source
Development could be done from a college dorm because open source platforms were used. The major cost was the cost of servers. I suspect Facebook continues to use open source platforms. No point building revenues for Oracle and Microsoft:-) Microsoft did at one time offer to buy Facebook. If that would have happened, I suppose they would have switched to Windows Server.
Lesson: FOSS provides a good platform for entrepreneurs. But be aware, that, "... while the software might have been free, it was not simple to operate." (pg38). Software wallahs wanting to use FOSS must be ready to invest time, or have already invested time, in learning the internals of the tools. It is an investment worth making.
Vision & Values
At one stage someone proposed to introduce an additional mouse click so that an additional ad could be shown. This was not acceptable to Zuckerberg as he was "fanatically devoted to making his service easy to use". Throughout the book there are numerous such examples. Though advertisers provide revenue, it is the users and their links that are the real assets of Facebook.
Lesson: Revenue, like costs, are constraints, they should not be the objective function.
Sustainable Growth
Pg 57-58:
"Every time the database was upgraded or the server array reconfigured, Zuckerberg tried to do it in a way that could accommodate ten times more users than TheFacebook had at that moment."
And again:
"So if the systems were acting up, capacity was at the max,or they couldn't yet afford new servers, they'd simply wait before launching at the next school. This was a rare asset at an underfinanced Web start-up. It allowed TheFacebook to grow methodically ..."
Lesson: Uncontrolled growth is a cancer. It can kill. Never let growth destroy the quality of the customer experience.
Growing after Assuring Demand
Pg 140: "By keeping the gates closed and only opening at schools once there was proven demand, Zuckerberg and Moskovitz, the expansion guru, ensured that when TheFacebook did open, usage would explode."
Lesson: Test your hypotheses about the market.
Not Cool
Being cool can get early adopters. But for Crossing the Chasm,
and then to get Inside the Tornado, and then to become a platform, you need to be perceived differently, and do things differently. And all along you need to consistently evolve your vision. The book is a study in how Zuckerberg did it.Work Place Silence
Pg 49: "When they sat at their laptops .... it was eerily quiet. That is because when they did talk to one another, they did over instant messaging, even when they were sitting next to one another." (emphasis is mine)
Again:
Pg 137: "One employee a few years older who sat about six feet from Zuckerberg in those days received an IM from the boss. "Hey," it read. It was the first time he had gotten such a message. So, seeking to be convivial, this guy stood up from his chair, turned to Zuckerberg, and said out loud in a friendly voice "Hey!" Zuckerberg continued staring blankly at his screen."
Comment: The workplace atmosphere should be that of a good college library. Not that of a canteen. This is more so for start-ups as they should not be spending money on private offices.
And Finally
Learn how to leverage social media for marketing your offering.
31 March 2011
Quality Control and Quality Assuarance
India Software Brief group on LinkedIn has a post on protection from bad software. The actions to be taken by an outsourcer (the one getting the software developed) are all necessary acceptance checks. The problem is what happens when the acceptance checks fail? Sure, reject the product but what happens to rolling out the services that depend on getting this software?
Acceptance checks can provide assurance that bad software does not get accepted. It does not provide assurance that good software will be delivered.
Far better to check the outsoursee's processes and be assured that the final acceptance checks will not turn up serious deficiencies or defects. An incremental model of development, with actual functioning code delivered would give a better estimate of the progress. This, of course, requires that the outsourcer put resources to test each increment and give feedback.
A while back I posted my views about QA and QC. The outsourcer must verify the QA processes and, by providing feedback on each increment, become part of QC. I suspect the root cause of all outsourcing horror stories lie in not doing this.
Acceptance checks can provide assurance that bad software does not get accepted. It does not provide assurance that good software will be delivered.
Far better to check the outsoursee's processes and be assured that the final acceptance checks will not turn up serious deficiencies or defects. An incremental model of development, with actual functioning code delivered would give a better estimate of the progress. This, of course, requires that the outsourcer put resources to test each increment and give feedback.
A while back I posted my views about QA and QC. The outsourcer must verify the QA processes and, by providing feedback on each increment, become part of QC. I suspect the root cause of all outsourcing horror stories lie in not doing this.
Cyber Weapons against Embedded Systems
Watch this video on Stuxnet.
I suppose the answer, for systems that can justify the additional cost, is not to use standard off-the-shelf hardware. The people who built stuxnet knew the details of the Seimens SCADA systems that run the centrifuges. They would also know the details of the centrifuges. Iran, like Pakistan, does not have the capability to build centrifuges. (India's nuclear programme, I think, does not require centrifuges.)
Not using standard hardware and firmware means building them in the country. Good news for Indian engineers.
Safety is one dimension of embedded software quality. Safety includes security against malicious attacks. Watch this webinar on security in eHealth.
I suppose the answer, for systems that can justify the additional cost, is not to use standard off-the-shelf hardware. The people who built stuxnet knew the details of the Seimens SCADA systems that run the centrifuges. They would also know the details of the centrifuges. Iran, like Pakistan, does not have the capability to build centrifuges. (India's nuclear programme, I think, does not require centrifuges.)
Not using standard hardware and firmware means building them in the country. Good news for Indian engineers.
Safety is one dimension of embedded software quality. Safety includes security against malicious attacks. Watch this webinar on security in eHealth.
25 March 2011
A Better Way of Putting it
A few days ago I posted on Optimization: Objectives and Constraints. Today I read Seth's post. He puts it much better.
Subscribe to:
Posts (Atom)