Aamir Khan attends to a customer complaint. The customer is surprised to find that Aamir is the managing director. Aamir replies, "Kaam bada ya chota nahin hota. Kaam, kaam hota hai." (Translation: A job is not low or high. A job is a job.)
No job is High. No job is Low.It is the standard of execution that is high or low. It is commitment that is high or low. It is professionalism that is high or low. A job is just that - a job.
29 September 2010
27 September 2010
Lessons from the Commonwealth Games: Hygeine
Lalit Bhanot, of the Organizing committee is reported to have said that our sense of hygiene differs from that of the other nations participating in the games. Some people, not unexpectedly, have been offended by that.
Let us take it that Mr. Bhanot was not taking of personal hygiene but rather of public hygiene. It would not surprise me if even that was contested by people responsible for public hygiene. I am sure they could come up with certificates that say that public hygiene is world class. It would surprise many that Noida has an ISO 9001 certification.
Certification is a one-off, or at best annual, event. A process has to be lived 24 x 7.
Bad hygiene, private or public, usually manifests itself as a bad odour. Bad code "hygiene" too usually manifest themselves as coding smells.
AntiPatterns are very closely related to coding smells.
Many years ago, acmet's Tools BU was confident it was doing good work for its Japanese customer. There was a regular flow of defects coming in, but the customer was not complaining about quality. Being Japanese they would have considered that rude. They hinted. We did not get the hint. One day the customer could not stand the "smell" any longer. They told us bluntly. That is when we started to improve our software development hygiene.
The regular flow of defects was a process anti-pattern that we failed to sniff (I apologize for mixing metaphors:-). As with personal hygiene, most times there will be no clear message for bad process hygiene. Learn to read the small tell-tale signs. Be paranoid.
Lessons
Get QA and developers to sensitize their noses to detect project and coding smells.
Certifications breeds smugness. Live the process 24 x 7.
Let us take it that Mr. Bhanot was not taking of personal hygiene but rather of public hygiene. It would not surprise me if even that was contested by people responsible for public hygiene. I am sure they could come up with certificates that say that public hygiene is world class. It would surprise many that Noida has an ISO 9001 certification.
Certification is a one-off, or at best annual, event. A process has to be lived 24 x 7.
Bad hygiene, private or public, usually manifests itself as a bad odour. Bad code "hygiene" too usually manifest themselves as coding smells.
AntiPatterns are very closely related to coding smells.
Many years ago, acmet's Tools BU was confident it was doing good work for its Japanese customer. There was a regular flow of defects coming in, but the customer was not complaining about quality. Being Japanese they would have considered that rude. They hinted. We did not get the hint. One day the customer could not stand the "smell" any longer. They told us bluntly. That is when we started to improve our software development hygiene.
The regular flow of defects was a process anti-pattern that we failed to sniff (I apologize for mixing metaphors:-). As with personal hygiene, most times there will be no clear message for bad process hygiene. Learn to read the small tell-tale signs. Be paranoid.
Lessons
Get QA and developers to sensitize their noses to detect project and coding smells.
Certifications breeds smugness. Live the process 24 x 7.
26 September 2010
Lessons from the Commonwealth Games: Deadlines?
The media has been reporting one Commonwealth Games deadline after another being missed.
What should happen when an activity misses its deadline? Should not the activity be declared dead? The outcome of the activity ceases to be relevant after the deadline. Why else call it a deadline?
The fact is these are not even estimated dates of completion. These are just ordered from on high: "Thou shalt complete this task by dddmmyyyy, or thou art dead". It may induce fear. It certainly does not get buy in. People get very adept at passing the buck. Forget about being dead, no one is even held responsible.
Does it happen in software companies? I am sure it does. At one time it used to happen at acmet's Tools BU.
Lessons
Remember, we deal with estimates. Not deadlines.
Estimates must be made by the people who have to do the execution.
Estimate, and re-estimate, on the basis of performance till date.
Do not hide the bad news.
Learn (Do the Hansei). It is better than fixing responsibility.
What should happen when an activity misses its deadline? Should not the activity be declared dead? The outcome of the activity ceases to be relevant after the deadline. Why else call it a deadline?
The fact is these are not even estimated dates of completion. These are just ordered from on high: "Thou shalt complete this task by dddmmyyyy, or thou art dead". It may induce fear. It certainly does not get buy in. People get very adept at passing the buck. Forget about being dead, no one is even held responsible.
Does it happen in software companies? I am sure it does. At one time it used to happen at acmet's Tools BU.
Lessons
Remember, we deal with estimates. Not deadlines.
Estimates must be made by the people who have to do the execution.
Estimate, and re-estimate, on the basis of performance till date.
Do not hide the bad news.
Learn (Do the Hansei). It is better than fixing responsibility.
Lessons from the Commonwealth Games: Media as QA
It struck me that the role played by the media in respect of the Commonwealth Games (CWG) is very akin to that of QA.
In software companies QA is part of the organization. It does have visibility into the process being followed. But, as often happens, management pays it lips service while concentrating on somehow "staging the games". When the schedule is under threat QA goes out the window. Being a part of the organization, it would be an extremely dedicated QA which would inform the customer.
On the other hand the media, though a part of the establishment, in India, is independent. Being independent they do not have official visibility into CWG organizing committe's processes. But they have their sources of information. However, no sources are needed when the result of the process is there for all to see. The media just have to report it. Where the result is not plainly visible, as in the case of the games village, it will be seen by the customer - the participating teams.
Did the CWG organizing committee have an internal watch dog? Did they listen when the watch dog barked? They could have had a good external QA if they had allowed the media visibilty into their process. By not having an effective QA the organizing committee did not get the bad news early.
Lesson for Software Companies:
Allow QA full visbility into the process. Get the bad news early. Do not shoot the bearer of bad news. Do not indulge in self-delusion.
In software companies QA is part of the organization. It does have visibility into the process being followed. But, as often happens, management pays it lips service while concentrating on somehow "staging the games". When the schedule is under threat QA goes out the window. Being a part of the organization, it would be an extremely dedicated QA which would inform the customer.
On the other hand the media, though a part of the establishment, in India, is independent. Being independent they do not have official visibility into CWG organizing committe's processes. But they have their sources of information. However, no sources are needed when the result of the process is there for all to see. The media just have to report it. Where the result is not plainly visible, as in the case of the games village, it will be seen by the customer - the participating teams.
Did the CWG organizing committee have an internal watch dog? Did they listen when the watch dog barked? They could have had a good external QA if they had allowed the media visibilty into their process. By not having an effective QA the organizing committee did not get the bad news early.
Lesson for Software Companies:
Allow QA full visbility into the process. Get the bad news early. Do not shoot the bearer of bad news. Do not indulge in self-delusion.
22 September 2010
Hacker Culture & acmet Tools BU
Further on an ealier post on the the subject.
The following quotes are from How To Become a Hacker by Eric Raymond.
#1. "There is another group of people who loudly call themselves hackers, but aren't. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people ‘crackers’ and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security doesn't make you a hacker any more than being able to hotwire cars makes you an automotive engineer."
#2. The basic difference is this: hackers build things, crackers break them."
#3. "Being a hacker is lots of fun, but it's a kind of fun that takes lots of effort. The effort takes motivation. Successful athletes get their motivation from a kind of physical delight in making their bodies perform, in pushing themselves past their own physical limits."
#4. "To behave like a hacker, you have to believe that the thinking time of other hackers is precious — so much so that it's almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually re-address old ones."
#5. "Authoritarians thrive on censorship and secrecy. And they distrust voluntary cooperation and information-sharing — they only like ‘cooperation’ that they control. So to behave like a hacker, you have to develop an instinctive hostility to censorship, secrecy, and the use of force or deception to compel responsible adults. And you have to be willing to act on that belief."
#6. "Therefore, you have to learn to distrust attitude and respect competence of every kind. Hackers won't let posers waste their time, but they worship competence — especially competence at hacking, but competence at anything is valued. Competence at demanding skills that few can master is especially good, and competence at demanding skills that involve mental acuteness, craft, and concentration is best."
#7. "If you revere competence, you'll enjoy developing it in yourself — the hard work and dedication will become a kind of intense play rather than drudgery. That attitude is vital to becoming a hacker."
#8. "Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). "
#9. "Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong — and we have no use for sloppy thinkers. If you can't yet write competently, learn to."
#10. "Learn to write your native language well. Though it's a common stereotype that programmers can't write, a surprising number of hackers (including all the most accomplished ones I know of) are very able writers."
So would a hacker culture have been acceptable? We certainly were well on the road to having one.
For those who worked on acmet's GCC porting project, please read this topic.
The following quotes are from How To Become a Hacker by Eric Raymond.
#1. "There is another group of people who loudly call themselves hackers, but aren't. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people ‘crackers’ and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security doesn't make you a hacker any more than being able to hotwire cars makes you an automotive engineer."
#2. The basic difference is this: hackers build things, crackers break them."
#3. "Being a hacker is lots of fun, but it's a kind of fun that takes lots of effort. The effort takes motivation. Successful athletes get their motivation from a kind of physical delight in making their bodies perform, in pushing themselves past their own physical limits."
#4. "To behave like a hacker, you have to believe that the thinking time of other hackers is precious — so much so that it's almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually re-address old ones."
#5. "Authoritarians thrive on censorship and secrecy. And they distrust voluntary cooperation and information-sharing — they only like ‘cooperation’ that they control. So to behave like a hacker, you have to develop an instinctive hostility to censorship, secrecy, and the use of force or deception to compel responsible adults. And you have to be willing to act on that belief."
#6. "Therefore, you have to learn to distrust attitude and respect competence of every kind. Hackers won't let posers waste their time, but they worship competence — especially competence at hacking, but competence at anything is valued. Competence at demanding skills that few can master is especially good, and competence at demanding skills that involve mental acuteness, craft, and concentration is best."
#7. "If you revere competence, you'll enjoy developing it in yourself — the hard work and dedication will become a kind of intense play rather than drudgery. That attitude is vital to becoming a hacker."
#8. "Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). "
#9. "Being a native English-speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong — and we have no use for sloppy thinkers. If you can't yet write competently, learn to."
#10. "Learn to write your native language well. Though it's a common stereotype that programmers can't write, a surprising number of hackers (including all the most accomplished ones I know of) are very able writers."
So would a hacker culture have been acceptable? We certainly were well on the road to having one.
For those who worked on acmet's GCC porting project, please read this topic.
Written Communication
I found the following in How To Ask Questions.
"Spell, punctuate, and capitalize correctly. Don't confuse “its” with “it's”, “loose” with “lose”, or “discrete” with “discreet”. Don't TYPE IN ALL CAPS; this is read as shouting and considered rude. (All-smalls is only slightly less annoying, as it's difficult to read. Alan Cox can get away with it, but you can't.)
More generally, if you write like a semi-literate boob you will very likely be ignored. So don't use instant-messaging shortcuts. Spelling "you" as "u" makes you look like a semi-literate boob to save two entire keystrokes. Worse: writing like a l33t script kiddie hax0r is the absolute kiss of death and guarantees you will receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm) in return."
I found the link as a polite postscript to a response on a forum.
The article contains great advice from a uber hacker.
"Spell, punctuate, and capitalize correctly. Don't confuse “its” with “it's”, “loose” with “lose”, or “discrete” with “discreet”. Don't TYPE IN ALL CAPS; this is read as shouting and considered rude. (All-smalls is only slightly less annoying, as it's difficult to read. Alan Cox can get away with it, but you can't.)
More generally, if you write like a semi-literate boob you will very likely be ignored. So don't use instant-messaging shortcuts. Spelling "you" as "u" makes you look like a semi-literate boob to save two entire keystrokes. Worse: writing like a l33t script kiddie hax0r is the absolute kiss of death and guarantees you will receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm) in return."
I found the link as a polite postscript to a response on a forum.
The article contains great advice from a uber hacker.
19 September 2010
Dogfooding - at acmet's Tools BU
We built and RENOVATED compilers at the Tools BU.
But we never used them.
One of the other BUs did applications for the same customer for whom we had built - and were maintaining - a compiler. Unfortunately, the applications were for processors other than the target of the compiler.
We were not eating the dog-food we were making. If we had, our tools team would have been the better for it.
But we never used them.
One of the other BUs did applications for the same customer for whom we had built - and were maintaining - a compiler. Unfortunately, the applications were for processors other than the target of the compiler.
We were not eating the dog-food we were making. If we had, our tools team would have been the better for it.
17 September 2010
New Toys
Seth's post reminded me of something that I have seen quite often with software developers.
Software developers want to work on new projects. Given the choice between finishing a project and joining a new project, hardly anyone opts for the former. It is in the begining phases, when the product is still "plastic" , that work seems more like play. It is like being in kindergarten. But if all a person does is move from one begining to another, the person will forever remain a beginner - no matter how many projects are put on the resume. The person will forever be in kindergarten.
It is only during the later phases, particularly the maintenance phase, that one gets to realize how things should have been done. That is when learning takes place. That is when one starts to become an expert. It takes time and reflection (hansei). There are no daily thrills. You do not get to play with new toys everyday. You have to study your old toy and learn how it should have been made. Then you can go and make better ones.
Software developers want to work on new projects. Given the choice between finishing a project and joining a new project, hardly anyone opts for the former. It is in the begining phases, when the product is still "plastic" , that work seems more like play. It is like being in kindergarten. But if all a person does is move from one begining to another, the person will forever remain a beginner - no matter how many projects are put on the resume. The person will forever be in kindergarten.
It is only during the later phases, particularly the maintenance phase, that one gets to realize how things should have been done. That is when learning takes place. That is when one starts to become an expert. It takes time and reflection (hansei). There are no daily thrills. You do not get to play with new toys everyday. You have to study your old toy and learn how it should have been made. Then you can go and make better ones.
13 September 2010
Documentation and Institution Building
MJ Akbar's article in yesterday's Times of India says, "Nehru and Patel wrote to each other when they sought to place a well-thought out policy position on record; they were, in a very real sense, creating precedence, administrative culture and an archive of an incubating government."
Nehru and Patel were part of a start-up. Their practice is worth emulating by other start-ups.
Nehru and Patel were part of a start-up. Their practice is worth emulating by other start-ups.
12 September 2010
Hacker Culture & acmet's Tools BU
A few weeks ago GGanesh, sent me an email about what he considered were the strengths and weaknesses of acmet's tools BU. In that he mentioned:
"But an acmet thing which I remember most, is the way we encouraged getting the bad news early. We definitely had the hacker's attitude. We played with the code and got the bad news early."
Did we really have a hacker attitude? I wondered if I would ever have been comfortable working with a bunch of hackers.
GGanesh's mail led me to Paul Graham's essay on hackers.
One paragraph in the essay says:
"The latest intellectual property laws impose unprecedented restrictions on the sort of poking around that leads to new ideas. In the past, a competitor might use patents to prevent you from selling a copy of something they made, but they couldn't prevent you from taking one apart to see how it worked. The latest laws make this a crime. How are we to develop new technology if we can't study current technology to figure out how to improve it?"
If it is good for progress to look inside the competitor's product, should practices that facilitate poking around inside's one's own product not be instituted? Poking around is reading (reviewing) code, poking values into variables while stepping through code, writing tests to see what breaks the code... Should not the product be constructed in a manner that makes future improvements easier? (The tag line for the Tools BU was "Software Maintenance as RENOVATION".)
So, yes I agree with GGanesh. And though the attitude was not strongly evident, it was getting stronger
Hindering Poking Around
This is my partial list of what hinders poking around.
* Inscrutable names of modules, functions, structures and data elements
* Prolific use of globals in the name of efficiency (a wolf in a sheep's clothes)
* Magic numbers
* Source code documentation that does not explain what sections of the code do and why it is required to be done, and what are the likely pitfalls.
* Undocumented pre-coditions and post-conditions
* Strong coupling between modules and weak cohesion within a module
* Cliques that discourage new generation of developers from getting to know the current code
Good Hackers
To make code easy to poke around, to bring up a new generation of developers, needs self-confidence and humility. Be critical of code, or ideas; not persons. I think most software companies would want such hackers. I definitely would have wanted more of them. That is the kind of hackers you want for a sustainable software process.
"But an acmet thing which I remember most, is the way we encouraged getting the bad news early. We definitely had the hacker's attitude. We played with the code and got the bad news early."
Did we really have a hacker attitude? I wondered if I would ever have been comfortable working with a bunch of hackers.
GGanesh's mail led me to Paul Graham's essay on hackers.
One paragraph in the essay says:
"The latest intellectual property laws impose unprecedented restrictions on the sort of poking around that leads to new ideas. In the past, a competitor might use patents to prevent you from selling a copy of something they made, but they couldn't prevent you from taking one apart to see how it worked. The latest laws make this a crime. How are we to develop new technology if we can't study current technology to figure out how to improve it?"
If it is good for progress to look inside the competitor's product, should practices that facilitate poking around inside's one's own product not be instituted? Poking around is reading (reviewing) code, poking values into variables while stepping through code, writing tests to see what breaks the code... Should not the product be constructed in a manner that makes future improvements easier? (The tag line for the Tools BU was "Software Maintenance as RENOVATION".)
So, yes I agree with GGanesh. And though the attitude was not strongly evident, it was getting stronger
Hindering Poking Around
This is my partial list of what hinders poking around.
* Inscrutable names of modules, functions, structures and data elements
* Prolific use of globals in the name of efficiency (a wolf in a sheep's clothes)
* Magic numbers
* Source code documentation that does not explain what sections of the code do and why it is required to be done, and what are the likely pitfalls.
* Undocumented pre-coditions and post-conditions
* Strong coupling between modules and weak cohesion within a module
* Cliques that discourage new generation of developers from getting to know the current code
Good Hackers
To make code easy to poke around, to bring up a new generation of developers, needs self-confidence and humility. Be critical of code, or ideas; not persons. I think most software companies would want such hackers. I definitely would have wanted more of them. That is the kind of hackers you want for a sustainable software process.
08 September 2010
Teach Sparrows
I find it mentioned quite often that one must have great/good programmers.
Maybe in the US, with an educational system that allows for a great deal of flexibilty, with more opportunities to play around with computers at a very young age, with electronic hardware being a smaller fraction of the average household income (as compared to India), it may be possible to determine proggrammer suitability at induction.
Most Indian looking to become software professionals have not had these advantages. So looking for great programmers is not a viable course of action. What we have to look for is the desire to prove oneself; the fire in the belly. That was a belief of my late friend, and boss, RR (the late Wg Cdr R Raghavan). I do not remember him to have ever asked a single technical question of any inductee.
Many of the people whom we took in at acmet (and earlier at Ergo) could not make campus placement. I am sure I am not wrong when I say that, today, all are with the some of the best brands in the business of electronics and software. They had the desire to prove themselves acmet (and earlier Ergo) provided the opportunity.
Guru Gobind Singh, the tenth guru of the Sikhs, said, ""I will teach the sparrow to hunt the hawk" .(quoted from Khushwant Singh's article).
My friend RR taught sparrows.
Maybe in the US, with an educational system that allows for a great deal of flexibilty, with more opportunities to play around with computers at a very young age, with electronic hardware being a smaller fraction of the average household income (as compared to India), it may be possible to determine proggrammer suitability at induction.
Most Indian looking to become software professionals have not had these advantages. So looking for great programmers is not a viable course of action. What we have to look for is the desire to prove oneself; the fire in the belly. That was a belief of my late friend, and boss, RR (the late Wg Cdr R Raghavan). I do not remember him to have ever asked a single technical question of any inductee.
Many of the people whom we took in at acmet (and earlier at Ergo) could not make campus placement. I am sure I am not wrong when I say that, today, all are with the some of the best brands in the business of electronics and software. They had the desire to prove themselves acmet (and earlier Ergo) provided the opportunity.
Guru Gobind Singh, the tenth guru of the Sikhs, said, ""I will teach the sparrow to hunt the hawk" .(quoted from Khushwant Singh's article).
My friend RR taught sparrows.
06 September 2010
Who Makes Product Specs?
Paul Graham in his essay on what happened to Yahoo says:
"I remember talking to some programmers in the cafeteria about the problem of gaming search results (now known as SEO), and they asked "what should we do?" Programmers at Yahoo wouldn't have asked that. Theirs was not to reason why; theirs was to build what product managers spec'd. "
Asking, "What should we do?" is not the same as, "Why is this required?" The programmers at Google were asking directions. They were not questioning the requirement.
The user requirement must come from the user. The product manager is the surrogate user.
But programmers too are users of software products. If they are building a search engine it should be one that they would willingly use. If the people making the dog food do not like it, neither will the dogs. And as far as finding out how the search engine could be misused, or gamed, the best inputs would come from programmers (if they are good programmers). In the absence of such converstaions what you have is a pin factory.
A good corporate culture would promote conversations between developers and users, or their surrogates. To get such a culture companies must select, and reward, persons who display this talent. Yahoo apparently did not.
"I remember talking to some programmers in the cafeteria about the problem of gaming search results (now known as SEO), and they asked "what should we do?" Programmers at Yahoo wouldn't have asked that. Theirs was not to reason why; theirs was to build what product managers spec'd. "
Asking, "What should we do?" is not the same as, "Why is this required?" The programmers at Google were asking directions. They were not questioning the requirement.
The user requirement must come from the user. The product manager is the surrogate user.
But programmers too are users of software products. If they are building a search engine it should be one that they would willingly use. If the people making the dog food do not like it, neither will the dogs. And as far as finding out how the search engine could be misused, or gamed, the best inputs would come from programmers (if they are good programmers). In the absence of such converstaions what you have is a pin factory.
A good corporate culture would promote conversations between developers and users, or their surrogates. To get such a culture companies must select, and reward, persons who display this talent. Yahoo apparently did not.
Subscribe to:
Posts (Atom)