Culture First

I posted yesterday about PSL, a software services company in Latin America.

They first got the culture of process driven software development firmly in place, before they decided to grow. If they had not done that quality would not have been sustained.

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.

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.

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.

Be Prepared for the Thorns

Is it okay to tell little lies and small promises?

No, they are habit forming. Quality software (or 6-pack abs) requires not fooling oneself, and meeting commitments, no matter how small.. As Seth points out, the worst lies are those that one tells oneself. It is true for organizations, as much as it is for individuals.

The customer wants 60 defects fixed in 6 months. Our documented record of the past shows we can expect to fix ~25 defects. That is what we commit to. The customer threatens that he will take his business elsewhere. Should we make a commitment and tell a lie? We did not. We met our commitment. The customer stayed with us.

We were to do a port of the GCC to a VLIW DSP. We committed to do a prototype port in five months. The customer wanted two months. We did not agree. We also said we would not give an estimate for the total port till we had done the prototype. Till that was done, we would also not take any money from them. After three months it appeared that we could not meet the five month target. We informed the customer that it would take us another three months. The customer was not willing to wait.

That is what not telling lies and false promises is about. It is tough. As an old song says, " ... You do not find roses grow on tops of clover". So if you want to commit to quality, be prepared for the thorns.

P.S. We continued with the GCC port. Unfortunately after a couple of months, owing to management problems in the company, we had to let go of our people. At the time the porting work was stopped, it appeared that we would have completed a successful port within the extended period of three months.

Organizational Learning

Good webinar on creating a learning organization.

The presenter makes his case using an example of an informal organization. So how valid is it in more formal organizations? I believe that the challenge for software companies is to have processes that nurture the behaviour displayed in the example.

"Shubh" Growth

The traditional hindu trader has "Shubh Labh" displayed somewhere on the premises of the business.

Shubh is commonly interpreted as good (e.g. "Aap Ka Shubh Naam" gets translated to "Your Good Name"). But Shubh rightly means auspicious. It describes a harbinger of good things to come.

So "Shubh Labh" does not mean just good profits. It means profits that will not damage the future of the business. That is "Ashubh Labh", or inauspicious profits.

So too with growth. There is "Shubh" growth. Growth that is sustainable; growth that ensures that the business conitinues to deliver value to its customers; growth that ensures that its people grow their portfolio of skills and their material well being.

Then there is "Ashubh" growth. Cancer too is growth. It is "Ashubh". It is growth that kills.


Growth can be a wolf in a sheepskin. Process Shepherds must watch out for it.