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.
29 August 2010
26 August 2010
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.
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.
23 August 2010
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.
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.
22 August 2010
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.
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.
20 August 2010
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.
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.
15 August 2010
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.
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.
11 August 2010
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.
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.
Subscribe to:
Posts (Atom)