Jugaad - Is it Good?

Two weeks ago Swaminomics talked of Jugaad as as our most precious resource. However, I do not think he is right about the origins of the term. I think it predates the appearance of tractors on the fields of the Punjab.

Jugaad rightly means a workaround - a term familiar to software wallahs (at least the ones who worked in acmet's Tools BU:-). In the workshops around Delhi it means the same - a workaround. If a piece of work cannot be held by a machine tool a "Jugaad" is quckly put together. Mechanical engineers study the subject under "Jigs and Fixtures". A jig or fixture, not build on solid mechanical engineering practices, is a jugaad. It will do the job today. But what of tomorrow? It will break after the first few parts are made and  kill or maim the machine operator. What of the tolerance limits of the parts? Will it be the same on the tenth part as on the first? Twenty years ago, I met a young mechanical engineer. Just after college, he had been working for couple of years in Delhi and was now preparing to go to Singapore. He said he was leaving as what you got in Delhi was expeience on Jugaad engineering.

Working around inconvenient laws of the land is also Jugaad. And Mr. Swaminathan Aiyar thinks that it is something that we should be proud of.

Jugaad is neither responsible engineering nor is it responsible citizenship.

Swapan Dasgupta in today's ToI has a rebuttal. I particulary liked the following :

"It has prompted a celebration of expediency, shortcuts and shoddiness. It has created a penchant for taking a winding course where a straight road should suffice. Once the escape route from hell, jugaad has now become an obstacle to India realizing its true potential."

The words remind me where we once were in the Tools BU.

Jugaad is papering up a broken window.

Jugaad, and any workaround, is a wolf in a sheep's clothing.

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.

Horsed Cavalry Mentality

GGanesh, who worked with me at acmet, sent me this link to a post by Paul Graham. The post decribes why, in Paul's view, Yahoo failed to see the opportunity that eventually Google seized.

Xerox's Palo Alto research center developed the mouse and GUI interface but Xerox defined itself in the office paper copier business. Apple took that and came out with its series of desktop computers that became the mainstay of desk-top publishing. IBM really grew the personal computer market with its open hardware architecture. But they did not realize the importance of holding on to the OS. That made Bill Gates the richest person in the world.

Success carries within itself the seeds of failure. Success creates a vested interest in preserving the status-quo. Individual careers, status, reputations, self-esteem, organizational "caste" system gets linked to maintaing the status-quo. But the business environment changes. Especially in an economy like the US, where it is easy to found companies and dissolve them and venture capital is more readily available, it is easy for a competitor to come up.

The Horsed Cavalry Mentality refers to the attitude of the British Army brass during the inter-war years. See pages 12 (middle) thru 15 of this RAND Corporation report. The folowing quote is particularly relevant:

"In spite of the experimental and strategic creativity of its leading military minds, the British army did little to overturn the antiintellectualism and lack of disinterested professionalism that permeated the traditional regimental culture. This was manifested by its unwillingness to develop and adopt effective combined-arms techniques. Infighting among the armored-warfare advocates compounded problems, as did the absence of a strategic vision."

Sounds like what happened at Yahoo.

The Akbar Effect

This appears to be a great tool for developing applications for Adroid phones and iPhones.

At acmet, in the tools BU, we made cross compilers and other tools for programming embedded applications. We also had a fairly competent in-house software infrastructure team that built our intranet, defect database query and reporting, accounts and HR system. Interestingly, we also had a group that was dedicated to an overseas customer, providing a USB product to mobile phone manufacturers.

With this much of apparent synergy, why did we not come up with the tool mentioned earlier? Because there was no synergy. Why was there no synergy? Because there was very little cross fertilization between teams. Why was there no cross fertilization? Because the senior lot - that includes me - distrusted each other.

A dysfunctional top management team cannot be expected to, first come up with, and then commit to, a new idea.

But did I get the idea? No, I did not, Why was that? I think because I am a late adopter. I could never see the point about the iPod. Never bought one. (Incidentally I bought a Walkman when it was at the end of its life cycle:-) I doubt if I will ever buy an iPhone:-( I am a techie. I guess, I am just not a gadget guy. And that, I think, is the reason. How can I possibly come up with an idea that links programming tools, and web 2.0, and mobile phones, if I do not have direct personal experience of them?

And that is, what I call, "The Akbar Effect".

The emperor Akbar was presented bibles by some missionaries visiting his court. Unlike the books in the emperor's library, these were printed books. But the emperor did not notice the difference. What if he had? It could have brought printing to India and set off an information revolution. Why did he not notice the difference? You see, Akbar, one of India's most powerful and enlightened rulers, was an illiterate.

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.

Commonwealth Games: Something Better Than Nothing?

Last Friday's Times of India (ToI) had a page on what should be done to save the games (CWG) from disaster. Basically it was roping in more people. Apparently they have not heard of the software project dictum - Throwing more people at a delayed project will not get it back on schedule.

Reminded me of how at one time we used make software deliveries:
Individuals busy with allotted tasks - no tracking, no reporting of daily/weekly progress.
No incremental delivery of working code.
No getting the bad news early - No daily build and smoke. (Did CWG have a means of getting the bad news? Were the bearers of bad news beheaded? Was the organizing committee hearing only what it want to hear?) 
No unit tests. Big bang testing towards the end.
Then slapdash defect fixes with undetected side-effects ("software malba"). No estimation of slippage.
No effective reviews of project artefacts. (What were CWG reviews like?) .
Cowboy coding. (Plenty of media reports about CWG's cowboy administration:-)
Heroic all-nighters in the last few days (ToI's suggestions).
Then ship "something" at 0400hrs, the day after the committed  date.
Declare success! (Kalmadi & co. will do the same).

Something better than nothing? Maybe; but, as a friend of mine said long ago, nothing is better than non-sense.

Incredible!

Watch this video.

Why have a biometric mechanism for preventing access, and then provide a regular lock and key in case the mechanism does not work?

If the biometric device is prone to malfunction (hence the need for a mechanical lock) why incorporate it at all? Why not spend on a better mechanical lock?

Lesson for testing: A system under test should be tested not only for what it is supposed to do (opens and with its key), but also that it does not do what it is not supposed to do (opens by any other means). To write tests for the latter is difficult. It needs knowledge of the implementation. It needs white box tests. It needs reviewers of code - and locks - to check for vulnerablity.

Reminds me of a true story. We had, in one our compilers, an implementation of some tricky optimization. Unfortunately it tripped up more often than it worked. The code had to be disabled. One of the developers was so attached to this clever piece of optimizing that he just could not bring himself to disable it. I suppose some people were attached to the biometric device.

"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.

False Certification

In an earlier post I had blogged about "Getting Ahead".

Times of India of 03Aug has an article that gives two examples of what happens when the desire to "get ahead" supercedes all values.

The DIG, who was held responsible for the Dantewada massacre, had in 1999, been decorated for liquidating three maoists. In fact he was nowhere near the scene of the action. False Certiciation. Falsification of records, and being on the right side of bosses can lead to awards. It will not lead to competent leadership.

The "ketch up" colonel, mercifully, had the values not kill his captives in cold blood. But then why stage a mock killing? To prevent a bad annual report, of course. That would stop him from "getting ahead". So False Certification,

What about many software companies with ISO/CMMI certification?

Measuring Software Productivity?

(Note: This was posted mistakenly while still being in draft. My apologies.)

Sapience, a start-up based in Pune, is reported to be developing a product to measure software productivity.

Before we start measuring it, how is software productivity to be defined? Over what period is it to be measured - daily, weekly, project duration?

The user, whether external or internal is interested in executable code that performs the functionality expected - nothing more, nothing less.

So the ratio of  functionality - as measured by function points, or executable lines of code - delivered to the user, to the staff-hours expended is, according to me, productivity. And it is the productivity of the team; not of individuals.

How many tests were written? How many reviews were held? How many lines of source code documentation were written? All these are meaningless to the user.

But these do effect quality. As such they should be measured.

Here is my partial list of metrics that should be captured (requirement collection, design phase metrics are not mentioned):
1. Lines of code (as accepted by the team/organization - e.g. the STXLN metric of QA C) added/changed and checked in.
2. Lines of test code added/changed and checked in.
3. Lines of source code documentation added/changed and checked in. The detailed design is in the source code files in Doxygen annotation.
4. Lines of code reviewed.
5. Number of defects reported/week.
6. Defect turn-around time (from the time it is reported till the time it is cleared).
7. Defect fix time (from the time it is assigned till the time it is cleared).

#1 thru #4 can be implemented using scripts and a version control system. At Acme Technologies we had this system but without automated metric collection.

#5 thru 7 can be obtained by having a MySQL database for defects and PHP scripts. This was implemented in Acme Technologies.

But do these metrics really tell the full story? What about lines of code that will never be executed? What about code that should go in to a function but is "in-lined"? What about lines of documentation that are incorrect, or verbose, or confusing, or just repeated? What about tests whose failures mean the same thing? For that, code, documentation, tests, and other artefacts must be reviewed diligently. Causal analysis must be done for defects found during product/integration testing. Do the hansei.

To get the story behind the numbers, a proper software development culture is required. Tools cannot build that culture. Only people can. As Collins says in Good to Great:  getting the right people "on the bus" is important. Tools, if properly used, can help. However, the real danger of tools that supposedly measure productivity, is that they can be easily misused by management

Individual metrics themselves are not as valuable as their trend over the duration of the project, and over different projects. The balance between the numbers too is important. No lines of code being changed could mean reviews, or tests, are inadequate. Lots of lines of code but few lines of test code could indicate a possible future defective product. It would also mean that test driven development (TDD) is not being followed (Why?).

How much is "lots"? How much is "few"? That calls for judgement. Judgement that is based on past data and its variance.

Take a car factory.

The only productivity figure that matters is the number of  defect free cars produced in a given time. But what if the cars cannot be sold in the same time? Is that productivity, or waste? Just-in-time or lean manufacturing considers that waste. Is the cars sold the productivity figure if most have to be recalled (witnesss Toyota)?

Let us go into the factory. What if the stamping macine produces only left doors in record numbers, and there are no right doors. Are the workers manning the stamping machine being highly productive. Lean manufacturing says, no. They are building inventory. And inventory is "muda" - waste.

Metrics are important. But do not put blind faith in metrics. Go and check what exactly is being practised on the ground. To quote Taiichi Ohno - “Data is of course important in manufacturing, but I place the greatest emphasis on facts.”

The complete team delivers business results. Components of the team do not deliver business results. Focus on the productivity of the team.