Temping

SiliconIndia has a post on temping.

How does one maintain quality when using temping? Jeffrey Liker in his book  Toyota Culture: The Heart and Soul of the Toyota Way explains how Toyota does it. He says:

The unique aspect of being part of the variable workforce at Toyota is that efforts are made to include the person as part of the "team" and the Toyota culture. To be sure there are pay and benefit differences and legal aspects that properly differentiate the two, but on the floor the same values of mutual respect and trust and continuous improvement hold true.

How many companies have a culture that allow this?

Value Stream Partners

This is  a rant - mostly.

A couple of days ago I attended a seminar by MathWorks about their products.

MathWorks has its only Indian office in Bangalore. That is not surprising, the bulk of the government hi-tech establishments are located there.

But Delhi too is important, after all it is where the headquarters of those establishments are located:-) So here they have partnered with a local company. They are part of the MathWorks value stream.

The "bandobast" (organization) - venue, registration, refreshments, lunch, gifts- for the seminar was done by the value stream partner.

I was informed, by mail from MathWorks, about my registration and asked to bring a printed copy of the mail. At the registration counter that mail was no help. The guys there had a handful of sheets listing names and organizations. There was a stack of pre-printed name cards. What was the problem in putting them in boxes according to the some ordering scheme? Better still why not keep a couple of small printers and print out the names on the spot?.I have seen electoral rolls checking, which is done by low paid government school teachers and other district staff, done better.

What does it say about MathWorks when its value stream partner does not know enough to put the lists on an Excel sheet? Does it need great administrative talent to allot a unique registration number to each participant? Is it expensive, compared to the expense of the venue, and the refreshments and lunch, to put a couple of laptops and a couple of printers at the registration counter?

The piece-de-resistance was the gift in exchange for the filled feedback sheet. It is good looking table clock. Nice big digits. The instruction sheet needs a magnifying glass. The day of the week cannot be set. Maybe some Chinese company designed it using a MathWorks product:-) Maybe all the clocks were not like that. Maybe, they fixed this one clock specifically for the guy who was making all that ruckus at the registration desk :D

Lesson: If your value stream partner interfaces with the customer, it is vital that you check the customer experience. Dog-fooding is more than eating the lunch served at the venue.

A Role Model for Entrepreneurs

This video on what it takes to build a successful venture was recommended by my friend Karnan.

Learn about dog-fooding, about values and vision.

QA Myths

Deloitte has a very educative document on QA myths.

Are Top Management's Sensory Channels Effective?

The collapse of a building gets the Chief Minister's attention, not this person's complaints.

My question: Can IT not be used to see that such citizen complaints are visible to the Chief Minister. Not just made visible but processed to extract information, spot trends, establish correlation, ... Delhi Traffic Police's Facebook page is an initiative that could be replicated and built upon.

What is the barrier to effective implementation? The political and administrative culture.

In a software company too, the culture and the values of the organization, can either sensitize, or de-sensitize, the sensory channels. The culture must re-inforce the value - get the bad news early. The culture must promote scientific checking for reality, the courage to face it, take corrective action, determine preventive measures and put them in to practice.

It is top management which, by its actions - not just words - communicates the culture and values.

With the wrong values even the most basic of business sensors, the balance sheet, is worthless - witness Satyam.

What is The Hard Part in Your Venture?

Finding and doing the hard part in your start-up is critical. It is leading from the front.

The trouble with leading from the front is knowing where the front is. The added problem is that the front keeps shifting. It is not just fighting fires. "Fire-fighting" gives an adrenaline rush. It can be addictive. You have to lead. But you have to also do the hard part, and that is putting "fire-prevention", "fire-detecting" and "fire-fighting" processes in place.

The hard part at any given time could be quality, productivity, raising financing, sales, seeing reality and changing the business strategy, people, ... Whatever it is, it has first to be identified. It is about spotting broken windows. And there could be more than one broken window.

In my view, getting the right people on the bus, and keeping them on it, and getting the wrong people off it, is always a hard part.

Can one person do it? Highly improbable. But a team with shared values, mutual respect, and interlocking skills, can.

At acmet we did not have such a leadership team.

Maintaining Software

Lack of maintenance results in a "Bhoot Bangla".

So too for software: RENOVATE it or demolish it. Do not carrying on living with it (or in it).

Oversimplifying

Einstein said, "Everything should be made as simple as possible, but not simpler". Watch Complexity leads to Simplicity

Meditation: The Power of Now

I have recently finished reading The Power of Now: A Guide to Spiritual Enlightenment, or rather my first reading of it. It is just 191 pages. I recommended it highly. Here are some things that I learned.

* The practices by which one can still the voice in one's head - the mind. Earlier I had read of it as "empty the mind of all thoughts". Never understood how to do it.

* My habitual procrastination was caused by the mind's fear of failure.

* There is "clock time" that is used for practical living. This is when the mind is required to be used

* And then there is "psychological time". The mind - the voice in the head - either keeps the past alive, or imagines a future. It distorts what exists now. When the mind is stilled one is aware of what exists NOW without judgement.

* The mind is stilled when in a deep dreamless sleep. Meditation has the same effect except that one's sensory perceptions are totally aware of the present. Many a times "sleeping on a problem" results in a creative solution. Meditation - putting the "voice in the head" to sleep - has the same effect.

Words, as Tolle says, are just road signs. They are meant to direct. They are not the destination.

My words above are meant to direct you to Tolle's book.

ADHAAR The UID Project

Believe the Hype by Thomas Friedman illustrates the grass-roots innovation opportunities that exist in India.

A few posts ago I mentioned that I attended the session on governance at the PAN-IIT 2010. My reason for doing so was that Nandan Nilekani was to speak about ADHAAR, the UID project that he is heading.

What the project is going to do is to allot a UID to every citizen after recording iris patterns and fingerprints. These will be maintained in a database. I suppose other data too would be maintained.

The database could be queried for delivering services to the citizen. I am sure it is going to open up new business opportunities.

Innovation: RoI

R & D need not be restricted to the parent company's business. R&D at Xerox is not. That is why they let Steve Jobs exploit PARC's innovations.

Constraints & Opportunities

Seth Godin has a post on Problems & Constraints.

Problems are within one's power to solve. Constraints are not. Constraints belong to the environment.

Problems are "pain points", the solutions to which are addressed by business plans. Constraints have to be catered for in the business plan.

But all constraints are not a law of nature like gravity. The earth will never become flat (not at least in a non-cosmological time frame). The world can, and has, become flat.

Technology, regulatory systems, social mores, demography, modify, or remove, constraints. Those who can spot the coming change in constraints, and have the capability to quickly ready themselves for it, can use it to their advantage.

Peter Drucker said that whenever distribution channels change, opportunities arise. The internet, not withstanding the dot-com bubble, has changed the way goods and services are distrubuted. That is what enabled Apple to change its business model - removal of a constraint.

PAN IIT: Session on Good Governance

This post is off topic.

The PAN-IIT Conclave was held from 29Oct to 31Oct at the Expo Center in Greater Noida. This was the first one that I attended. I think I was the person living the closest to the conclave site. It would have been inexcusable if I missed the opportunity to meet with some people I have not met with for four decades.

One of the sessions was on good governance. Arvind Kejriwal was a speaker. Most of what he had to say about ineffective and toothless investigating agencies, appeared in his article of 02Nov in the ToI. What is missing from the article is the passion with which he delivered his talk. Listening to him I thought he was an activist like Medha Patkar, or Arundhati Roy. Only later did I learn that he is an alumnus of IIT Kgp. Well IITs produces all sorts of people. Some even join the Indian Air Force:-).

An examle that he gave during his talk, and which does not appear in his article, is that of how Hong Kong rooted out of corruption. I doubt if anyone, other than Mr. Kejriwal, believes that solutions that can be implemented in Hong Kong (now, or pre-unification with the PRC), can be implemented in a federal, multi-party, democracy. I believe that one place to begin is to make the accounts of political parties auditable and available in the public domain. That will go a long way to break the political-mafia nexus. Chandrashekar when he was the PM, was once asked about it by a reporter. The video shows the PM dismissing it out of hand.

An interesting episode. The audience being a bunch of techies were very appreciative of Mr. Kejriwal's passion. Mr. Kejriwal, sensing the reaction, felt that he would do better by speaking in Hindi. There was an immediate uproar from a number of people. Vociferously prominent amongst them were two IIT Madras guys sitting with me - one of them my batch mate, another a couple of batches junior. Apparently the spirit of 1965 lives on:-) Arvind largely stuck to English after that. It would have been a blast  had Neelakeni, who spoke after Arvind, taken a leaf out of Kanimozhi's  (I hope I got the spelling right) book and addressed the audience in Kannada, or Tamil. So much for PAN-IIT guys having a PAN-Indian perspective:-(

Leadership

Seth Godin says, "It requires education and coaching and patience to create a team ..." in this post. Exactly the same as teaching sparrows.

Open-Book Job Interviews

I doubt if many of us would be as productive if we did not google. Google is a secondary/tertiary store of information for most professionals. A good "primary" memory is an advantage, but not in the way it was in pre-Google days.

The other day I was speaking with a young friend. He works for a well known software MNC. He mentioned that in an interview that he had conducted, the candidate had responded to a question by saying that he could get the information by googling. The candidate failed.

I have been thinking about that. If the candidate failed because of his dependence on Google, it was a mistake. I think he should have been allowed access to the Internet to get the information. After that the interview should have been about ability to process the information in a job related situation.

In college, machine design exams were open-book exams. With Google being available ubiquitously, there is no reason the job interviews too should not be "open-book".

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.

Lessons from a Software Company in Columbia

Do you know what are CIVETS? I knew they were a type of cat but I did not know that the acronym stands for Columbia, Indonesia, Vietnam, Egypt, Turkey, South Africa. Incidentally South Africa also occurs in BRICS.

Watch this webinar about PSL, a small software company in Columbia. I thought Columbia was synonymous with drug cartels. Hardly the place for software companies. The webinar was an eye-opener.

Marketing of Services. Sometime in 2007 I realized that we were not marketing acmet's Tools BU correctly. Acmet's marketing talked of all the products that we had made for others. There was nothing about our people and our processes. I came to realize that we had to put our developers, the people who lived the process, right in front where prospective customers could talk to them. We had to display aretfacts of our process as part of sales talk. Unfortunately, it was too late. Nonetheless, it is gratifying that the webinar validates the approach.

Watch the video on PSL's site. Hear why Latin Americans have an advantage over Asians (read Indians) :-)

Code Comments, Process Worth

Yesterday I was leafing through Guy Kawasaki's, "Reality Check". I had read it a year ago. There were many statements that resonated with me. Here are two of them.

Code Comments
"Luckily the lack of comments usually doesn't matter, because the code is so crappy that a total rewrite is necessary in year."

Lack of comments is a bad smell.

Process
Quoting Stanford psychology profesor Carol Dweck, Guy says, "Instead of praising children's intelligence or talent, focus on the processes they used."

And at the end of the chapter: " ... focus on the process worth ethic, not the inherent brilliance, of your employees."

At acmet's Tools BU we certainly did that.

Innovation: Staffing

Govindarajan & Trimble , as mentioned in an earlier post, describe the Performance Engine and the Dedicated Team and why they should be distinct. The book also mentions the need to have a proper relationship between the two so that the resources, skills and knowledge of the Performance Engine can be effectively leveraged.

Context To Core
Geoffrey Moore, in his book Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution, speaks of the need to allocate from Context to Core. Context consists of whatever the company needs to do to stay in the game. Core is what the company needs to do to stay ahead in the game - and that is innovate. (Watch video of Geoffrey Moore on Context and Core in the Software Industry). However, Geoffrey Moore does not deal with the barriers to allocating from Context to Core and how to overcome them. Govindarajan & Trimble do that.

Moonlighting
Givindarajan & Trimble advise against trying to do worthwhile innovation with people working in their slack time. It is not as if such "moonlighting" cannot come up with ideas or small victories, or incremental improvements. What they fail at is, in the words of the book's title, "the other side of Innovation".

Concerning Startups: There are startups where the "entrepreneurs" are not entrepreneurial enough to quit their regular jobs. Such a startup is is not a place to be employed; nor are these people to be doing business with. At acmet we dealt with one such firm.

Missing Performance Engine
I mentioned in an earlier post that a startup, unlike an established organizatiion,  has a Dedicated Team with no associated Performance Engine. It has its advantages; it is not burdened by the past. But that is also a disadvantage. The startup does not have a brand. It does not have a set of customers who trust it.

Mitigation: These diadvantages can be mitigated, to an extent, if the entrepreneurs have worked in the industry in various roles - production, product development, marketing & sales. They should be known within the industry and to customers who use the products and services of the industry.

When RR & I started Ergo Electronics we lacked this. We could have overcome this disadvantage. I suppose hubris prevented us, both then, and later at acmet, from never really being able to so.

Postscript
With this post I have ended my current set of takes on Govindrajan & Trimble's book.

If you work at an established company, the book will help you understand what your company needs to do if wants to innovate. Maybe you could suggest what needs to be done, and why.

If you intend to start a venture, or are already in one, I hope my posts would have motivated you to read the book.

Thank you for your attention.

Innovation: The acmet Tools BU Experience

In my last post I mentioned the estimation funnel. The funnel is caused by the non-routine nature of any innovation initiative. Any software work, which is non-routine for the organization, is subject to the estimation funnel (see slide 2 of this document). It is an innovation initiative.

At acmet's tools BU, for the maintenance work that we did on our compilers, we could, with a fair degree of accuracy, estimate and commit to targets. These were routine. We did, on the other hand, construct a dsp compiler, an assembler, a linker, an elf to IEEE695 format converter, an assembly to assembly converter. These were innovation initiatives for us.

Govindarajan & Trimble list 10 principles to formalize experiments. One of them is: Find ways to spend a little, learn a lot. They characterize unknowns along two axes - consequence of being wrong, extent of ignorance. The ones with the most serious consequences and with the highest degree of ignorance are the ones that are most critical. These should be resolved first. That is precisely what protyping and incremental development is about. The authors give the example of how IBM used prototyping to for the development of the Blue Gene supercomputer.

Tools BU Experience
Initially, we made commitments to the customer that we failed to keep. We learned. We learned to develop incrementally. We learned to prototype. We learned to do the learning as an in-house project and not subject ourselves to pressures caused by schedules based on pure guesswork. Of course in-house projects have a perception problem.

At the time acmet decided to close operations, the tools BU was working on porting the GCC to a VLIW DSP. This was, for us, the most innovative. And we did go about setting up experiments to resolve unknowns. The project had as its first target, a prototype that would generate code for an FIR routine. The target was to match the performance of hand coded assembly. Most importantly, though we had a prospective customer, I refused to commit to firm dates. I admitted that all I had were guesses, not estimates. At the time I did not know it, but what we were really engaged in was a rigorous learning process.

Innovation: Established Organizations & Startups - Learning Process

In my earlier post I mentioned that Govindarajan & Trimble describe a rigorous learning process.

The effect of a rigorous learning process is that estimates become progressively more accurate over time. They illustrate it with a diagram. The diagram is precisely what softwarewallahs call "The Estimation Funnel"! (See my post on Estimation).

Estimates are based on hypotheses about cause and effect; they are of the form if < action.> then &lt;result>. Hypotheses, as in the scientific method, must be tested by experimentation. Evaluation of results must be free of biases (the authors describe these biases). Adhering to the sceintific method is what makes the learning process rigorous.

The genesis of all startups too are a set of hypotheses. These concern pain points, market size, value provided, revenue streams, costs, ... All of that goes into the business plan. The business plan is a set of hypotheses about business reality. It is not business reality. The rigorous learning method is required to evolve the business plan to conform more closely to reality.

The authors provide a simple graphical tool for recording the hypotheses. They call it a "hypothesis of record". They illustrate it with an example of how Analog Devices actually put it to use.

Further, the acts of making the business/innovation plan and rigorous learning cover, in my opinion, the first three steps of the Shewhart PDCA cycle. Not surprising, as continuous quality improvement too is based on hypotheses.

Innovation: Established Companies & Start-ups - The Business Plan

In continuation of my earlier post.

Quote from Govindrajan & Tremble's book:
"Given the uncertainities involved, writing an innovation plan can feel like writing a work of fiction. The predictions in them are wild guesses. Indeed in many cases, those trying to sell the intiatiative have deliberately stretched the projections to make the return on investment look better".

That is pretty much applicable to business plans made by start-ups. So what is the value of a business/innovation plan? The authors say:
"The value of an innovation plan is that it serves as a benchmark for subsequent learning." (Emphasis is mine).

By learning, the authors do not mean some academic, ivory tower stuff. They define, what they call a "rigorous learning process". Start-ups too should adopt the same process. I shall talk about it in my next post.

Innovation: Established Organizations & Start-ups

Vijay Govindrajan & Chris Trimble's book on Innovation is about innovation at established companies. The book explains why established organizations find innovation difficult and offers them a prescription. Nevertheless, I think the book is essential reading for persons running start-ups and small companies. What follows, in this and a few subsequent posts are my take-aways from the book.

Innovation consists of two parts - the idea and then its implementation. Ideas are the easy part. It is in successfully implementing ideas that established companies falter. The reason is that established companies evolve for efficiency. The authors call them Performance Engines. Performance Engines value predictability, small variance, and meeting targets. Performance Engines have past data . Innovation implementation have no past data for making forecasts. The authors state bluntly, "The first rule of innovation is simple: Innovation and on-going operations are always and inevitably in conflict" (italics are the authors'). Therefore, the team responsible for implementing the innovation must be distinct from the Performance Engine.  "Each innovation initiative requires a team with a custom organizational model and a plan that is revised only through a rigorous learning process" (emphasis is mine). They name such a team as the Dedicated Team. It is good partnership between the Dedicated Team and the Performance Engine that leads to successful innovation by established companies.

The way I see it, all start-ups, and small companies, are Dedicated Teams without an associated Performace Engine. Thus, what the authors have to say about the Dedicated Team, apart from the relationship with a Performance Engine, is of value to start-ups. I will post on some of these in following posts

Innovation: Skunk Works

The problem with having hackers is that most are pretenders. As Paul Graham says, "This attitude is sometimes affected. Sometimes young programmers notice the eccentricities of eminent hackers and decide to adopt some of their own in order to seem smarter. The fake version is not merely annoying; the prickly attitude of these posers can actually slow the process of innovation."

So what do you do with the pretenders? Obviously they must be got rid of. Who best to do it than the real hackers. In a company that is no longer a startup that would be problematic. I think one solution is to have a something on the lines of Lockheed's legendary Skunk Works, where innovative, and highly successful, aircraft like the U-2, the SR-71, and the Stealth fighter were created.

Skunk works need to be separated from the normal, on going, revenue generating, business. It needs to be run with different policies and controls for personnel, finance and administration. Skunk Works: A Personal Memoir of My Years of Lockheed gives some idea of how a skunk works is run.

Problem for Small Software Companies
At acmet's Tools BU the GCC port was, in some ways, a skunk works operation.Some of the people on customer-billed projects regarded it as a glorfied on-bench tenure. Some of the people on the project - some time or the other - also felt that they were on-bench. This, I feel, would happen in most small software companies.  It is the job of the senior manager, responsible for the skunk work project, to counter such perceptions.

Clarification
Innovation does not mean invention. A number of people may have done it before, but if for us it is new, then we are being innovative. The innovation need not necessarily lie only in the product. It can lie in the process, or the services bundled with the product. The GCC port work had never been done by us before. It was going to be a new business model for us. For acmet's tools BU it was innovative.

Estimation

Interesting set of slides on Estimation.

Slide 2: Is the estimation "funnel"

Slide 11: acmet's tools BU fell in the Nominal category.

Slide 14: For 10K lines (I do not know how these are defined - whether they include data definitions, unit tests, documentation, ...) 10 calendar months and 48 (say 50) staff-months. That is 10 lines/day ((10K/50 staff-months)/20 days/staff-month). That is somewhere near the figure that we got. Also, no mention is made of the expected residual defects.

I have a thumb rule: The number of residual defects per 1K XTSLN equals the effective XTSLN/staff-day over the elapsed time. At 10 XTSLN I would expect about 10 defects/1K XTSLN. Of course to get 0 defects/1KXTSLN we would be coding at an effective rate of 0 XTSLN/staff-day. That is not as odd as it may sound. To reduce to zero defects one would require infinite time.

(Note: XTSLN is a Lines of Code metric defined and measured by the QA C tool)

Slide 18: This is my favourite. It illustrates the estimation funnel. Note
the relative error column. There is not even 1 negative entry! For a 5 year
project the estimate becomes accurate 3 months prior to ship.

Slide 22: Note the last bullet.

Slide 23: **** Worth remembering *****

Slide 26: These are all the recovery techniques.
Note: Praying is *** not *** a recovery technique.

CWG: Time To Do The Hansei

The Commonwealth Games by all accounts went off well. That it was headed for a disaster will soon be forgotten. If we do get the 2020 Olympics there is every likelihood that we will again prepare for it in the same manner.

A large complex project, involving multiple government agencies, with no option of slippage requires a highly skilled and motivated management team. And since the national image is involved, the team must have access to, and the whole-hearted support of, the highest rungs of the political leadership. Suitable talent should be shortlisted. The UID project, headed by Nandan Nilekani, brought in with the status of a Minister of State in the Union cabinet, should be the model.

Based on the current experience, we need to create a project plan - complete wih check lists (e.g. signs near building housing the ozzie team saying,"Beware of Falling Refrigerators:-). The project plan must be periodically reviewed and updated since financial conditions, technology, security environment, facilty benchmarks, vendors, ,, all will change. The sports ministry should do this, if we are serious about conducting the 2020 Olympics.

Holding enquiries into alleged siphoning of funds, punishing the guilty, assuming any are found, is all very well, but it will not reduce the chances a repetition.

For that we need to do the Hansei.

Rituals

Today is Ayudha Puja.

My father, sometime after he past 70 years, gave up driving. He then employed a driver. My father continued to regularly check the battery water, the radiator water, tyre pressure. He would ensure that the car went for its regular monthly servicing. On Ayudha puja he did not apply sandalwood paste to the car, nor bedeck it with flowers. The drivers would do that.

I like to think my father performed the puja that was required.  Rituals must be appropriate.

Software processes too are rituals. They are rituals which provide the assuarnce that your software does what it is meant to do. They are rituals that have to be performed continuously, and concurrently with writing the code. Applying sandalwood paste, turmeric, and burning incense will do nothing for the code (nor for your keyboard, nor your display).

Greetings for Dussehra: May you never let the demons get into your code. If they do, then may you always slay them at the earliest.

Do Not Emulate Dronacharya

The national award for sports coaches is the Dronacharya award.

Dronacharya played politics. First he would not accept Eklavya as his students on grounds of race. Next when Eklavaya coached himself and became better than his star pupil, Arjun, Dronacharya managed to ensure that Eklavaya would not be the best archer of his time.

If Indian coaches play favourites, why blame them. They are emulating Dronacharya.

Lesson for Software Coaches: Do not play favourites.Nurture talent without any heed to caste, or creed, or region.

Humility & Courage

Some of those who have worked with me would remember this.

Two absolutely indispensable character traits for software work.

Humility - to say, "I do not know". Never believe anything is a piece-of-cake. There are going to be surprises. Never think your work output is defect-free.

Courage - to move forward knowing that there are unseen pit-falls. It is the courage of a blind person. Do not be afraid of falling. Feel your way. Experiment; take small steps; make mistakes; admit them; and learn from them.

Custom Processors

Tenselica gives ten reasons to customize a processor.

What about the tool chain? Should be a business opportunity for porting the GNU tool chain.

Movie about Quality

Early today I watched Executive Suite. It is a movie made in the the 1950s. I strongly recommend getting the bittorrent download, or the DVD (available from Amazon), or watch when Turner Classic Movies schedules it again

The terrific cast include William Holden. Holden was a favourite of mine when I was in school. Some may remember him from Bridge On the River Kwai. The movie very convincingly conveys the message about values on which a company should be run, quality in manufacturing, product that the company's people are proud to stand behind. If American companies had paid heed they would not have lost leadership in automobiles. We need to build companies with the same values.

High Jobs and Low Jobs

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

What do Embedded Software Engineers Really Do?

A great post by Colin Walls.

What *** really *** resonated with me is what he says about maintenance, “efficient” (quote marks are Collin's) code, keeping it simple, writing code that is readable by non-expert humans, commenting (and then commenting some more).

“Efficient” code is another wolf in a sheep's clothing.

Orange Rubber Boots in Action

How to behave in a disaster. Lessons from BP for IT

Six Action Shoes & Software Process

Grey Sneakers. Informal. Lounging - going nowhere. Creative juices. Lateral thinking. (Use the Six Thinking Hats: White, green, red, yellow, black, &  blue).

Brown Brogues. Path finding through unfamiliar terrain. Scouting alternate routes. Prototyping. Decide on the way ahead.

Black Dress Shoes. (what we normally refer to as formals) Draw up a formal plan. Instrument it. Execute.

Purple Riding Boots. Use of formal authority. Monitor, assess, provide feedback. Take corrective action.

Pink Slippers. The human touch. Team building activities. Diffuse inter-personal tensions.

Orange Rubber Boots. For emergencies. The customer will be in trouble. Locate the defect. Make the work around. Pull all-nighter. Then Analyse cause (Grey sneakers and/or Brown Brogues). Take corrective action (Black dress shoe, or Purple Riding boots). Note: If you wear Rubber Boots for too long, your feet will smell. So will your process. This is an anti-pattern.

Wolves In Sheeps' Clothing

1. Sheep's Clothing - Customer Orientation. Wolf - scheduling not based on reality; under priced.
2. Sheep's Clothing - Quality Certification. Wolf - Lip service to quality.

3. Sheep's Clothing - Quality Department. Wolf - Quality is no longer the responsibilty of developers.

4. Sheep's Clothing - Productivity. Wolf - Unmaintainable code; "indispensable" coders.
5. Sheep's Clothing - Heroic Efforts. Wolf - Create emergencies; no learning; "indispensable people;

Certfication & Quality

Todays Swaminomics talks of how the award for Corporate Social Responsibilty does not correlate with actual behaviour towards society.Both BP and Goldman Sachs had received it. Recent damage caused by these companies show that social responsibilty was not a value. It was mere PR glitter.

Quality certifications, like the award for Corporate Social Responsibilty, can be obtained with the required "paper work" and some amount of play acting. It does not mean that Quality is a prime value for the company. In most cases it is obtained for adding glitter to marketing. And all that glitters is not gold.

Quality has to be a basic value. A value expressed not through certfications, or  on the web-site, or in quality manuals. It has to be the gating criteria for all product decisions. It has to be expressed through action. Actions speak louder than words.

Deepwater Horizon Oil Rig, "Bhoot Banglas" & Wolves in Sheep's Clothing

Deepwater Horizon, the oil rig in the Gulf of Mexico that blew up was a "Bhoot Bangla". 

This Bhoot Bangla was not created overnight. There were a series of broken windows that no one attended to.

(see more on this)

Why did no one attend to the broken windows? I quote from the article: "... drilling priorities taking precedence over planned maintenance". That was the wolf in sheep's clothing. And there was no process shepherd.

(PS: I apologize for the mixed metaphors:-)

White Paper on Software Quality

Good article on sustainable software quality improvement.

Eternal Vigilance

Eternal Vigilance is the Price of Liberty - Thomas Jefferson.

Without vigilant civil society, civil liberties will get eroded.

So too is eternal vigilance the price for Quality.

Quality needs shepherds to protect processes  from being slowly decimated by the wolves, most in sheep's clothing, lurking in the forests of software development.

Getting Ahead

Last Saturday Prof Ananth, Ditector IIT Madras, addressed the alumni in the NCR area.

During the talk the need for inculcating values came up. Prof Ananth narrated how during one of his interaction with some of his students he was told that there was nothing wrong with "cogging" (copying) as the objective was to get ahead! I suppose some "dudes" thought it "kewl" to tell the director that.

Would you want such a person as a colleague? What about as a researcher? How about for testing your mission-critical software? Or designing nuclear power plants?

Values are not learned in colleges, or in organizations. Display of wrong values needs examplary punishment.

Values are learned primarily at home and school. They are absorbed from the social environment and need correction at home.

And can a person who copies really "get ahead"? Like athletes taking performance enhancing drugs to get ahead, there are damaging, long term side-effects. The getting ahead is very transitory.

Expand Your Box

At acmet we used to build (and maintain) compilers. Compiler builders must know the strong and weak points about compilers for similar target MCUs. Sales of processors depend upon the tool support provided. It can be the deciding factor for choice of an MCU. That means compiler builders must be familiar with competing compilers and their target architectures. This task calls for experienced tool builders.

Tool builders must also be fully aware of the expectation of the users. They must be able to talk the application developers language. People who build a compiler for a DSP must have some understanding of DSP techniques. It is familiarity with the application domain that can lead to targetted customization, to relevant pragmas, and appropriate libraries.

I came to this realization a bit too late:-(

Do not become a pin factory worker. Follow Seth Godin's advice.

A Fun Place to Work

So what is fun at the work place?

Here are some things that I consider fun at the work place:
 * Making commitments - and meeting them.
 * Finding preventive measures for defects.
 * Helping colleagues better their knowledge.
 * Writing software that is not hard to understand - or at least not harder than necessary.
 * Writing the tests to prove that the code does what it is meant to do - and not do.
 * Taking equal pleasure in others fun.

Here are some things that I definitely do not think as fun at the work place:
 * Practical jokes.
 * Jokes on other people's physical characteristics, or mannerisms. This I find particularly detestable. Mercifully I have never been in such a workplace.
 * Disturbing others - loud talk, raucous laughter ...
 * Offensive language

The second list is a partial list of  ill-mannered behaviour. An ill-mannered person does not show consideration for another's feelings. An ill-mannered person lacks empathy. An ill-mannered person is about "me". Do you want such "funny" persons at your work place? Should not the selection and retention process, select and retain persons with a sense of fun suited to the work place? Should not the process ensure that "funny" persons are rejected, or promptly ejected?

To Err is Human ...

To Err is Human; to Forgive - Divine

But to Forget is Stupid!

Create, or modify software, and defects will be introduced. Penalize individuals for it and defects will be be swept under the carpet. Team cohesiveness will disappear. So forgive - and forget - the person.

But to forget, what led to the defect being introduced. To forget to learn from it. To forget to put preventive practices in place. That would be stupid!

Do the hansei.

Optimization - Seth Godin & Geoffrey Moore

Seth Godin in a recent post advises against spending time on optimizing something that is doing well enough. Rather it is better, after a certain stage to spend time on creation.

Good advice for individuals. And for businesses too. I recommend one should read Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution for a clearer - and longer - exposition.

Geoffrey Moore defines the state of a company along two axes - Core, and Context. Core represents activities/products that provide differentiation from the competition. Context is everything else that a business does to stay in the game. .

A product progresses from being high-Core + low-Context, to high-Core + high-Context, to low-Core + high-Context, and finally to low-Core + low-Context.

It is in the later two states that optimization - including outsourcing - come into play. It is also during the third stage that it becomes important, to use Geoffrey's words, to "extract from Context and allocate to Core".

I think Seth's advice fits in with "extract from Context and allocate to Core". And that optimization can only take the business so far.

Here is a  a video of Geoffrey Moore explaining these concepts to an audience of software developers.

Broken Windows & Bhoot Banglas

Ever come across tests that are no longer in sync with the specifications/requirements? Code that has been modified but the specification/ requirements document has not? Changes made but no comments in the version control log? No version control? Defect fixes lead to side-effects destabilzing the code?

If you have, then you have come across a bhoot bangla (a broken-down haunted house).

Bhoot Banglas start with broken windows. Code that is not documented is a broken window. A requirement that cannot be traced to implementation and a test, is a broken window. A defects that is not caught in review is a broken window. A Magic numbers is a broken window (and replacing 1 by defining it as ONE does not make it any less magical). Unrestrained use of globals is a broken window. Unrestrained coupling is a broken window. A broken test is a broken window.

Look actively for broken windows. Fix broken windows as soon as they are noticed. Do not wait for a big clean-up phase. Do your good deed for the day.

The book Broken Windows, Broken Business: How the Smallest Remedies Reap the Biggest Rewards has great relevance to software development and maintenance. As it says in the introduction a "broken window" is "any small indication that something is amiss and not being repaired". It leads to much larger problems.

Broken windows result in Bhoot Banglas. And Bhoot Banglas result in broken software people.

Quality Control Feedback Loop

In yesterday's post I mentioned Quality Control (QC) is finding the defect in the process, or its implementation, and then fixing it.

Inadequate training would, in many cases, be a major contributing factor. How much time is spent on training? Is the training process suited to the people selected by the selection process? Are people evaluated on evidence of process practices?

Yes, quality needs the commitment of the CEO. Commitment both by word and deed.

As the tag-line of this blog says: Quality is like six-pack abs - hard to get; hard to maintain.

QA or QC?

We send our product for testing before shipping. Some tests fail. We fix the defects and send it again for testing. This time it passes.

What did we do - QA or QC?

Neither.We fixed defects. Period.

Only the process that we used to make the product, can provide Assurance of Quality.

Defects reaching final testing indicates some flaw in the process, or in its implementation. We need to ask: Why was the defective code not caught in review? Why did unit testing not catch it? Were the specifications, clear & complete? ...

It is when we investigate the cause of the defects reaching final testing, and institute corrective measures, that the feedback loop is completed. There can be no control without feedback. Only then does Quality Control (QC) happen.

Excellence

"We are what we repeatedly do. Excellence is therefore not an act but a habit" - Aristotle

The above quote was in an email that I received.

I am sure that something was lost in translating from classical Greek to English.

Surely just repeatedly doing something out of habit will not improve us in whatever we are doing. If we are to improve in doing something, surely how we do it must change. Continuing to do something in a manner because it was always done so, would still have us hanging from trees.

It is the PDCA (Plan, Do, Check, Act) cycle - not just repeatedly Doing (the D part) - that will move us towards excellence.

Yes making the PDCA cycle a habit will lead to excllence.

Who is your Customer?

This is a question I frequently used to ask our new inductees. Invariably the answers gave one of the company's customer.

Whoever uses a team member's output is that team member's customer. If  the member has written a class, then any other member who uses that class is a customer. If the customer has problems in using the class it must be treated as a "customer" complaint, attended to promptly, and the root cause found and rectified. The customer is not to be lectured and told as to how he can change his code.

If the code is hard to understand, or not well documented, or with incomplete unit tests, then the customers (those who will review the code) are being treated badly.

Then there are people who will maintain the code long after you are gone; they too are your customers.

Growing and nurturing such an attitude is a defining part of team and company culture.

Kaizen: The Key To Japan's Competitive Success. (I have the international Edition of 1991.) On page 51 it has a sub topic, "The Next Process Is The Customer". Then on page 135, while describing cross functional management at Toyota - "The overriding goal is to never inconvenience downstream customers."

There is a lot that software companies can learn from Toyota.

Shutting Down Acme Technologies

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.

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.

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.

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.

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

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.