Finally, last week we took the decision to close down Acme Technologies. The writing on the wall was there for sometime now but some of my colleagues on the board did not see it. Our current commitments will be completed by September. By the end of Mar2011 we should be able to down shutters
Happily all our people have been placed well. This was because they were all kept in the picture about our revenue position.
The root cause, as I see it: No shared values within the top management.
Where I failed: Realizing too late that I had to get more proactive in marketing.
30 June 2010
28 June 2010
Pixars Practices
Pixar Animation Studios have produced many animation hits (Cars, Finding Nemo, Toy Story, Ratatouille, ...) They certainly qualify as a creative organization.
There is an article about the company in the Economist of Jun 19th, 2010.
Here are two practices that I think software companies should emulate:
1. " ... the company devotes a lot of effort to get people working together. ... Pixar, however tries to foster a sense of collective responsibility among its 1,200 staff." The article says that Pixar got the inspiration for this from the Toyota Production System.
2. It is obligatory for teams to conduct a post mortem after a film is completed. The post mortem must list atleast five things that went wrong and as many that did not.
There is an article about the company in the Economist of Jun 19th, 2010.
Here are two practices that I think software companies should emulate:
1. " ... the company devotes a lot of effort to get people working together. ... Pixar, however tries to foster a sense of collective responsibility among its 1,200 staff." The article says that Pixar got the inspiration for this from the Toyota Production System.
2. It is obligatory for teams to conduct a post mortem after a film is completed. The post mortem must list atleast five things that went wrong and as many that did not.
Specialization and the Software Practicioner.
What of the perspective of the individual practioner? Should he become a specialist? I believe sticking with a specialization would be career threatening. I believe the key skill is to be able to quickly become a competent practioner, in any of the skills required for the software life cycle. That is also what good team work is about.
26 June 2010
Clients or Customers?
I have always been averse to the use of the term "clients" in the IT business.
The Concise Oxford Dictionary (10th edn.) gives the first meaning as "a person using the services of a professional person or organization". It gives the meaning of the term in Middle English as "a person under the protection and patronage of another".
Lawyers have clients. Chartered accountants have clients. Bosses of political parties (other than left wingones) have clients.It is a relationship of power to harm. And of course doctors & psychiatrists have the greatest power. They have patients. And gurus have chelas.
Lawyers, CAs, political bosses, doctors & psychiatrists do not entertain clients. Clients are expected to entertain them!
Do lawyers, CAs, doctors, psychiatrists compete with other lawyers, CAs, doctors and psychiatrists in the manner say Wipro competes with Infosys? Do they have sales guys? Do they make presentations to their clients?
They do not charge a price. They charge fees. (Gurus have guru dakshina.) Do they negotiate with clients? Do their clients question them about their cost structure?
What we have are not clients (usually pronounced as Kly-ints). We have customers. See this quote from the Mahatma on Zoho's site. Incidentally, I saw this quote, a few decades ago, on a poster in the Khadi Bhandar shop on Connaught Circus. The shop assistants paid it no heed.
Peter Drucker said, "The purpose of a business is to create a customer". Can a doctor say the purpose of his practice is to create a sick person? Or a lawyer say that the purpose of his practice is to get more people to file litigations?
We have customers. Customers have the power.
The Concise Oxford Dictionary (10th edn.) gives the first meaning as "a person using the services of a professional person or organization". It gives the meaning of the term in Middle English as "a person under the protection and patronage of another".
Lawyers have clients. Chartered accountants have clients. Bosses of political parties (other than left wingones) have clients.It is a relationship of power to harm. And of course doctors & psychiatrists have the greatest power. They have patients. And gurus have chelas.
Lawyers, CAs, political bosses, doctors & psychiatrists do not entertain clients. Clients are expected to entertain them!
Do lawyers, CAs, doctors, psychiatrists compete with other lawyers, CAs, doctors and psychiatrists in the manner say Wipro competes with Infosys? Do they have sales guys? Do they make presentations to their clients?
They do not charge a price. They charge fees. (Gurus have guru dakshina.) Do they negotiate with clients? Do their clients question them about their cost structure?
What we have are not clients (usually pronounced as Kly-ints). We have customers. See this quote from the Mahatma on Zoho's site. Incidentally, I saw this quote, a few decades ago, on a poster in the Khadi Bhandar shop on Connaught Circus. The shop assistants paid it no heed.
Peter Drucker said, "The purpose of a business is to create a customer". Can a doctor say the purpose of his practice is to create a sick person? Or a lawyer say that the purpose of his practice is to get more people to file litigations?
We have customers. Customers have the power.
25 June 2010
What Defines a Person?
What defines a person is not what the person can, or cannot do. What defines a person is what the person can do, but chooses not to do.
And that choice reflects a person's values.
Rejecting cowboy coding. Instead adhering to coding standards, not accepting "the language permits it" as a reason, doing test driven development, documenting and intentional naming so future generation will find it easier to maintain the code...
And that choice reflects a person's values.
Rejecting cowboy coding. Instead adhering to coding standards, not accepting "the language permits it" as a reason, doing test driven development, documenting and intentional naming so future generation will find it easier to maintain the code...
Is Literature Relevant?
Great article in today's Times of India on the relevance of what Dickens wrote and the current economic woes of the Euro zone.
Great literature is about the human condition - emotions, weaknesses, strengths ... It is about how humans relate to one another - both individually and collectively. It is about the human impact of economic and political issues. Since human beings have not changed over the past centuries, great literature continues to be relevant.
To understand the impact of the industrial revolution, it is not enough to read economics and history, one must also read Dickens. The reverse is equally true. To understand Dickens one must read the history and the economics of his time.
This is true of all great literature, irespective of language. To more fully understand the economic and historical conditions of a society, or a civilization, one must be at least familiar with its literature.
Unfortunately the education of techies neglects literature. To that extent we remain stunted.
Great literature is about the human condition - emotions, weaknesses, strengths ... It is about how humans relate to one another - both individually and collectively. It is about the human impact of economic and political issues. Since human beings have not changed over the past centuries, great literature continues to be relevant.
To understand the impact of the industrial revolution, it is not enough to read economics and history, one must also read Dickens. The reverse is equally true. To understand Dickens one must read the history and the economics of his time.
This is true of all great literature, irespective of language. To more fully understand the economic and historical conditions of a society, or a civilization, one must be at least familiar with its literature.
Unfortunately the education of techies neglects literature. To that extent we remain stunted.
19 June 2010
Dogfooding - Getting the Customer Experience
I wanted an additional TataSky connection. I logged on to my account to buy one. There is no apparent way in which I could do this on-line. I went to the contact us page which has two levels of selections. You have to select the first level then see if the relevant choice is available at the second level. I was lucky enough to have found the relevant choice on the 2nd first level choice. Is it very customer friendly? What if my subject did not match any of the sub-categories?
Why not just give an email-id - contact-at-somecompany.com? Are the sales/customer-care people so busy that they cannot figure out what to do unless it is bureaucratically fitted into some category?
Do C level executives see such mail?
More importantly, how many executives actually visit their sites as a customer, or ask their friends and relatives to do so?
American managers have a saying, "If you make dog food, you must eat it". That is getting the customer experience. Do not count on the dog filling out a feedback form:-)
I know we did not dogfood the programming tools we made :-(
Why not just give an email-id - contact-at-somecompany.com? Are the sales/customer-care people so busy that they cannot figure out what to do unless it is bureaucratically fitted into some category?
Do C level executives see such mail?
More importantly, how many executives actually visit their sites as a customer, or ask their friends and relatives to do so?
American managers have a saying, "If you make dog food, you must eat it". That is getting the customer experience. Do not count on the dog filling out a feedback form:-)
I know we did not dogfood the programming tools we made :-(
17 June 2010
Lateral Entry & Startups
My late friend, and boss, Raghavan (RR) used to say, "We will not take industry-corrupted persons". And we never did. We always recruited from colleges and grew our own team and project leads.
Startups would be well advised to follow RR dictum. As a startup it is very important to form the culture of the nascent organization. You have to get the right people on the bus (watch Jim Collins video). And the best way to do it is to get people who can still be easily molded.
Startups would be well advised to follow RR dictum. As a startup it is very important to form the culture of the nascent organization. You have to get the right people on the bus (watch Jim Collins video). And the best way to do it is to get people who can still be easily molded.
Software Development Practices
This is the content of an email that I sent to the people that I worked with in the programming tools business unit. The email was sent in Jul 2003. By and large these were adopted by most of the developers of the business unit and continued to be practised over successive generations of developers. The practices were well ingrained and I doubt if later generation of developers were even aware that such a mail existed:-)
The practices were based on my reading of the following references:
1. Steve McConnell: "Rapid Development". Microsoft Press (WP Publishers, India)
2. Steve McConnell: "Code Complete". Microsoft Press. (Indian Publisher: WP Publishers)
3. John Robbins: "Debugging Applications". Microsoft Press (WP Publishers, India)
4. Steve Maguire: "Writing Solid Code". Microsoft Press (WP Publishers, India)
5. Masaki Imai: "Kaizen - The key to Japan's Competitive Success". McGraw-Hill International Editions
Documentation
See:
"Comment, Comment, Comment, And Comment", pgs77-78 of Ref3.
"Self-Documenting Code", Ch19 of Ref2.
"PDL for Pros", pgs54-57 of Ref2.
Please remember documentation is for YOUR customer. Who is your customer? Anyone who has to look at your code, or use it, is your customer; the developer who uses the services that your code provides, the reviewer, the tester, the maintainer, and last but not least - you. It is documentation that transcends space and time. To paraphrase (I think, Wordsworth), "Dust thou art to dust returnest was not spoken of documentation"
Comments need to convey what's in the developer's mind, not what a given statement is doing. Explain the "What & Why". Only then, explain the "How"
Two quotes from Ref3:
"I mean documenting your assumptions, your approach, and your reasons for choosing the approach you did."
"Donald Knuth once observed that you should be able to read a well-written program just as you would read a well-written book."
Develop the code in a three-stage step-wise refinement process. The artifact of each stage is to be reviewed.
First Function Headers. Function header should contain the algorithm. If it is from a text, then give the reference. The algorithm should just explain the broad idea of how the purpose of the function will be achieved. If the algorithm is getting unwieldy, it means more than one function is required. The algorithm has to be reviewed before proceeding.
Next PDL. The PDL refines the algorithm. Check if indeed it does that. The PDL must be in a style that will make them good comments.
Next Code. The final refinement. Check if algorithm, PDL and code are consistent.
Any changes to the code should be reflected back to the PDL and if necessary to the algorithm. The reasons for the changes should be given in the comments.
The DETAILED DESIGN, inclusive of functional specifications, will exist only in the source files, as file and function headers. NO WHERE ELSE.
Only the architecture design will exist as a separate document. It will be largely pictorial and show the interconnections and responsibilities of the modules. This document should be a part of the workspace.
NAMING CONVENTION: Follow the Hungarian Notation.
ASSERT
Read:
"Assert, Assert, Assert, And Assert", pgs48-58 of Ref3
"Assert Yourself", Ch2 of Ref4
And implement.
Globals
No globals. Any relaxation, to this rule, will only be made with the permission of the CEO.
Use Access routines. See pg231-233 of Ref2.
Test Each Function
Read:
"Step Through Your Code" Ch4 of Ref4
"Trust Yourself, But Verify (Unit testing)" in Ref3 pgs78-80.
Walk-thru your code by stepping thru every path.
Daily Build
Read:
"Daily Build and Smoke Test", ch 18 of Ref1
Get the bad news early!
Do this even on one-person projects.
A smoke test is just an indicator that the build has a reasonable chance of passing the full test and therefore, development can continue. If the full test throws up defects that necessitates the development to regress, then the smoke test is not adequate.
Creation of tests is a creative activity and will require the attention of skilled and experienced persons.
The further away we are from Daily Builds the more defect prone is our development process.
Daily Check-out and Check-in
Even on one-person projects use the CVS. Check-out the files at the start of the workday. Check them in at the finish of the workday.
Defects
All defects are to be recorded in the DTS (Defect Tracking System. This was implemented as a MySQL database).
Defect analysis does not finish with identifying the cause. Like Taiichi Ohno ask "Why?" five times (pg50 of Ref5). Analysis must identify reasons that caused the defect to be introduced; the reasons that caused it to be missed in unit tests. It must identify the remedial measures that need to be introduced in the development process.
Defects caught in reviews must also be recorded in the DTS and analyzed.
Checklists
The results of defect analysis must result in entries in checklists.
Each of the chapters in Ref2 ends with a checklist. Browse the book and choose your top 10. Use it when reviewing your own code or someone else's. Save a copy.
Keep records
Keep records, preferably as text emails, of all discussions and reviews. If it was not recorded, it did not happen.
Keep it Simple
"Finally, don't write code the way lawyers write contracts." - pg166 of Ref4
Use the QA C to keep a check on the complexity of your code. Document this metric in the function/file header.
The practices were based on my reading of the following references:
1. Steve McConnell: "Rapid Development". Microsoft Press (WP Publishers, India)
2. Steve McConnell: "Code Complete". Microsoft Press. (Indian Publisher: WP Publishers)
3. John Robbins: "Debugging Applications". Microsoft Press (WP Publishers, India)
4. Steve Maguire: "Writing Solid Code". Microsoft Press (WP Publishers, India)
5. Masaki Imai: "Kaizen - The key to Japan's Competitive Success". McGraw-Hill International Editions
Documentation
See:
"Comment, Comment, Comment, And Comment", pgs77-78 of Ref3.
"Self-Documenting Code", Ch19 of Ref2.
"PDL for Pros", pgs54-57 of Ref2.
Please remember documentation is for YOUR customer. Who is your customer? Anyone who has to look at your code, or use it, is your customer; the developer who uses the services that your code provides, the reviewer, the tester, the maintainer, and last but not least - you. It is documentation that transcends space and time. To paraphrase (I think, Wordsworth), "Dust thou art to dust returnest was not spoken of documentation"
Comments need to convey what's in the developer's mind, not what a given statement is doing. Explain the "What & Why". Only then, explain the "How"
Two quotes from Ref3:
"I mean documenting your assumptions, your approach, and your reasons for choosing the approach you did."
"Donald Knuth once observed that you should be able to read a well-written program just as you would read a well-written book."
Develop the code in a three-stage step-wise refinement process. The artifact of each stage is to be reviewed.
First Function Headers. Function header should contain the algorithm. If it is from a text, then give the reference. The algorithm should just explain the broad idea of how the purpose of the function will be achieved. If the algorithm is getting unwieldy, it means more than one function is required. The algorithm has to be reviewed before proceeding.
Next PDL. The PDL refines the algorithm. Check if indeed it does that. The PDL must be in a style that will make them good comments.
Next Code. The final refinement. Check if algorithm, PDL and code are consistent.
Any changes to the code should be reflected back to the PDL and if necessary to the algorithm. The reasons for the changes should be given in the comments.
The DETAILED DESIGN, inclusive of functional specifications, will exist only in the source files, as file and function headers. NO WHERE ELSE.
Only the architecture design will exist as a separate document. It will be largely pictorial and show the interconnections and responsibilities of the modules. This document should be a part of the workspace.
NAMING CONVENTION: Follow the Hungarian Notation.
ASSERT
Read:
"Assert, Assert, Assert, And Assert", pgs48-58 of Ref3
"Assert Yourself", Ch2 of Ref4
And implement.
Globals
No globals. Any relaxation, to this rule, will only be made with the permission of the CEO.
Use Access routines. See pg231-233 of Ref2.
Test Each Function
Read:
"Step Through Your Code" Ch4 of Ref4
"Trust Yourself, But Verify (Unit testing)" in Ref3 pgs78-80.
Walk-thru your code by stepping thru every path.
Daily Build
Read:
"Daily Build and Smoke Test", ch 18 of Ref1
Get the bad news early!
Do this even on one-person projects.
A smoke test is just an indicator that the build has a reasonable chance of passing the full test and therefore, development can continue. If the full test throws up defects that necessitates the development to regress, then the smoke test is not adequate.
Creation of tests is a creative activity and will require the attention of skilled and experienced persons.
The further away we are from Daily Builds the more defect prone is our development process.
Daily Check-out and Check-in
Even on one-person projects use the CVS. Check-out the files at the start of the workday. Check them in at the finish of the workday.
Defects
All defects are to be recorded in the DTS (Defect Tracking System. This was implemented as a MySQL database).
Defect analysis does not finish with identifying the cause. Like Taiichi Ohno ask "Why?" five times (pg50 of Ref5). Analysis must identify reasons that caused the defect to be introduced; the reasons that caused it to be missed in unit tests. It must identify the remedial measures that need to be introduced in the development process.
Defects caught in reviews must also be recorded in the DTS and analyzed.
Checklists
The results of defect analysis must result in entries in checklists.
Each of the chapters in Ref2 ends with a checklist. Browse the book and choose your top 10. Use it when reviewing your own code or someone else's. Save a copy.
Keep records
Keep records, preferably as text emails, of all discussions and reviews. If it was not recorded, it did not happen.
Keep it Simple
"Finally, don't write code the way lawyers write contracts." - pg166 of Ref4
Use the QA C to keep a check on the complexity of your code. Document this metric in the function/file header.
Why Have an Office?
Seth Godin has a post on Goodbye to the office. For a software company the real work no longer requires an office.
An office is required for legal/taxation purposes. A company is an entity independent of its members and requires a "brick-and-mortar" address.
The office now fulfills a social role; provides a sense of belonging to a group; provides some sense of identity; as Seth says, it meets "I need some place to go".
I have practised it for some years now. And at the tools BU that I headed, we had no problem in permitting people who wanted to work from home, to do so. I am based in Noida. The tools people, except for 4 persons, were all based in Chennai. Owing to our process I had no problem in keeping track of what was happening.
I would however, like to add a caveat. Working remotely is not for everyone. It calls for a great deal of self discipline.
An office is required for legal/taxation purposes. A company is an entity independent of its members and requires a "brick-and-mortar" address.
The office now fulfills a social role; provides a sense of belonging to a group; provides some sense of identity; as Seth says, it meets "I need some place to go".
I have practised it for some years now. And at the tools BU that I headed, we had no problem in permitting people who wanted to work from home, to do so. I am based in Noida. The tools people, except for 4 persons, were all based in Chennai. Owing to our process I had no problem in keeping track of what was happening.
I would however, like to add a caveat. Working remotely is not for everyone. It calls for a great deal of self discipline.
11 June 2010
A Great Developer is ...
A post on the art of debugging. I absolutely agree with Lalit. See an an earlier post of mine.
07 June 2010
Software Companies and the Pin Factory
A person I have met on a few occasions, is a believer in specialization. He gives the example of Adam Smith's pin factory. (On all occasions it was to convince people to stick to testing).I confess to being suspicious of specialists.
Should a software company -especially a start-up, or a small company - be run like a pin factory?
My perspective is that of 10~150 person software company. Not of an Infosys or a Microsoft. I do not know those worlds.
The pin factory method of organizing work came true in the assembly lines of the 20th century. The dehumanizing aspect of such work was potrayed in the classic film Modern Times, starring Charlie Chaplin. The justification of the pin factory model is that it is efficient and thus leads to higher higher production. That is true for mass production where tasks are repetitive. The human operator is first exxpected to become an automaton. Then the worker is replaced by an automaton.
But is software development, or maintenance, mass production? Can software tasks be done in a mechanical way with minimal engagement of the persons mind? There are such tasks like doing builds and running tests and they should be automated through scripts. But that does not mean that testing should be treated as a specialization.
Personally I think that a software company should be organized and run as described in A Company of Citizens: What the World's First Democracy Teaches Leaders About Creating Great Organizations
. One of the authors, Brook Manville, was the Chief Learning Officer at Saba Software..
Subscribe to:
Posts (Atom)