This a scene common enough in most examination halls in India.
There are some who keep writing till the invigilator comes and yanks the answer book from them.
There are others who pace themselves and spend the last 30 mins of the 3 hour examination (16% of the "development" time), revising (reviewing) their work.
What about all-night cramming before the exam vs. study spread through the semester?
Which one does your process look like?
Which one would you like it to look like?
Just In Time is easy to misapply.
27 February 2012
What Keeps Defects Hidden?
My top five:
1. No daily build and smoke - failure to get the bad news early
2. No unit tests
3. No reviews
4. Code that is hard to understand (follow Linus Thorvald's guidelines)
5. Aggressive scheduling leading to Muri
So when code is not subjected to these it is like work-in-progress widgets inventory piling up at a machine. It is inventory piling up.
Okay the code works fine, passes all the tests, but there is no user manual. Or it is hard to modify because it is a Bhoot Bangla (going slightly off topic see an oil rig that was one).
When we say we have shipped, did we ship a finished product or was it work-in-progress?
1. No daily build and smoke - failure to get the bad news early
2. No unit tests
3. No reviews
4. Code that is hard to understand (follow Linus Thorvald's guidelines)
5. Aggressive scheduling leading to Muri
So when code is not subjected to these it is like work-in-progress widgets inventory piling up at a machine. It is inventory piling up.
Okay the code works fine, passes all the tests, but there is no user manual. Or it is hard to modify because it is a Bhoot Bangla (going slightly off topic see an oil rig that was one).
When we say we have shipped, did we ship a finished product or was it work-in-progress?
19 February 2012
Just In Time for Software
As a readers of this blog would know, I am a great admirer of the Toyota's quality process. I believe that the processes are applicable to software development and renovation.
What puzzled me for a long time was this: How can Just In Time (JIT) apply to software? Software production does not depend upon inventory. To make the second copy of a software product does not require another set of parts to be procured.
Then one day I was talking to my son Vijay, who is a supply chain guy, about Just In Time. He said, "Daddy, Just In Time is about showing up problems in the process".
That was it. I had been looking at the mechanism, not the purpose it was meant to serve.
A software process that exposes defects early is a JIT process.
Which of course begs the question: What is it that keeps defects hidden?
What puzzled me for a long time was this: How can Just In Time (JIT) apply to software? Software production does not depend upon inventory. To make the second copy of a software product does not require another set of parts to be procured.
Then one day I was talking to my son Vijay, who is a supply chain guy, about Just In Time. He said, "Daddy, Just In Time is about showing up problems in the process".
That was it. I had been looking at the mechanism, not the purpose it was meant to serve.
A software process that exposes defects early is a JIT process.
Which of course begs the question: What is it that keeps defects hidden?
06 August 2011
About Hats
Watch this video about a company that makes hats. The same management attitude is required for software companies. I believe my late friend RR practised this.
17 July 2011
Coding Productivity
Some days back Ramy sent me this link. A some what in-extenso quote from the article:
I believe that that was at the core of our development process at acmet's Tools BU.
An earlier post on measuring software productivity is relevant to the subject.
“… To the contrary, they fully understand that few things are more foolish, dangerous and pathologically counterproductive than superficial productivity measures. Great coders don't just write great code, they grasp the essence of problems in ways that makes their code architectures clean, accessible and maintainable. The code not only works, other coders — perhaps less talented — can safely and creatively build on it, with it and for it.
Their code costs less to support and evolve even as it invites and facilitates new value creation. Only the technically naive and economically inept see code as a software deliverable that programmers should produce on time, on budget and on spec. People who really know what they're doing appreciate the lifecycle and ecosystem economics of their efforts."Note: The emphasis in the above is mine.
I believe that that was at the core of our development process at acmet's Tools BU.
An earlier post on measuring software productivity is relevant to the subject.
Japanese Industrial Culture & Software
A decade ago Mr. Yuasa, a customer of acmet's, asked me, 'How is it that India is so good at software". My short answer to him was, "Because we are not good at anything else!" My reply was not entirely in jest.
This was my thesis, progressively strengthened over the years:
1. The large semiconductor companies that we dealt with did not value software tools (acmet developed and maintained compilers for them).
2. They made their money selling processors. Tools and their maintenance they gave away free to support sales. It was a pure cost that, if not made zero, had to be minimized. (In a way that helped us, as otherwise they would never have outsourced tool development.)
3. The top decision makers had made their careers and reputations developing, manufacturing and selling chips - drams, processors, ... The semiconductor companies had software talent but I doubt if they really had the respect of top-management.
4. Unlike what some of my colleagues believed, Japanese software talent was strong. Evidence of that was their dominance in games and in robotics.
The Jul 16th - 22nd 2011 issue of The Economist has an article titled, "Samurai go soft", with the subtitle, "Japan's preference for hardware over software is fading". Here are some quotes:
In 2008, I remember, a large Japanese conglomerate was interested in investing in acmet. But then the financial melt-down happened. The rest, as they say, is history :-(
This was my thesis, progressively strengthened over the years:
1. The large semiconductor companies that we dealt with did not value software tools (acmet developed and maintained compilers for them).
2. They made their money selling processors. Tools and their maintenance they gave away free to support sales. It was a pure cost that, if not made zero, had to be minimized. (In a way that helped us, as otherwise they would never have outsourced tool development.)
3. The top decision makers had made their careers and reputations developing, manufacturing and selling chips - drams, processors, ... The semiconductor companies had software talent but I doubt if they really had the respect of top-management.
4. Unlike what some of my colleagues believed, Japanese software talent was strong. Evidence of that was their dominance in games and in robotics.
The Jul 16th - 22nd 2011 issue of The Economist has an article titled, "Samurai go soft", with the subtitle, "Japan's preference for hardware over software is fading". Here are some quotes:
"A samurai would never write software!" barked a senior executive at one of Japan's biggest electronics firms, ....
.. by bundling programs with machines, they taught customers that software was of little value.The article mentions that, among others, "Hitachi and Toshiba are hunting for software firms". I wish this had happened earlier - or acmet were still around.
In 2008, I remember, a large Japanese conglomerate was interested in investing in acmet. But then the financial melt-down happened. The rest, as they say, is history :-(
05 June 2011
Source Code Comments
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.
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.
Subscribe to:
Posts (Atom)