The Darzi's Process

Darzi is the Hindustani word for a Tailor.

A darzi is the person one went to have an item of clothing "developed". The steps:

1. At a bare minimum one had to tell the darzi the Requirement - Trouser, or Coat, or Shirt, or Suit, ... 
2. The darzi then made various measurements. Assuming the requirement was for a pair of trousers, he would get your inputs about how high you wore your trousers, the position of the trouser cuffs, how loose/tight the fit at different points, the number of back pockets, whether they had to have flaps, the number of loops for the belt, etc. In short, he would determine the Product Specifications. All done  interactively with the customer (you). The specification would be meticulously quantified and documented by the darzi's assistant (an entry level developer). Very Scrum!
3. He would then give you an estimate of the material required, the cost, and the expected schedule.
4. The delivery would normally be in two stages (sprints?). The first milestone, called a trial, or fitting, would be a functional product that you the customer, could try out.  It was for interactive customer feedback. (very Xtreme!). This intermediate deliverable would be architected for ease of modification. 
5. The feedback received would be used to make the adjustments so that the final deliverable would result in your satisfaction.

Question: Would a darzi accept fuzzy Requirements, or fuzzy Specifications, or not Documenting the specification, or skip the Customer Feedback intermediate step?

Naive Software Wallahs

I agree with Seth Godin that Being professional means making measurements.

I think at the very minimum basic code coverage  metrics should be captured and tracked. Can it be claimed that a function is "done" without it having been tested? Can it be said to have been tested without the basic code coverage metrics having been recorded? Accepting a function to be "done" without even the basic code coverage metrics is being Naive.

Software is of value to the business entity that owns it. It is a business asset. Assets need to be maintained. Complex code is error prone and hard to maintain. Accepting that a function is maintainable without measuring Cyclomatic Complexity is being Naive.

Making, and accepting, schedules without having past performance metrics is being Naive.

Commitment- Lessons from Indo-Pak (1971) & India-China (1962)

I recently read Arjun Subramaniam book "INDIA's WARS". On pg342, he describes how, in April 1971, Indira Gandhi was a "trifle disappointed" when Gen Manekshaw, the Chief of Army Staff, did not agree to launching an attack immediately on what was then East Pakistan. Manekshaw asked till December. Indira Gandhi deferred to Sam Bahadur.

Manekshaw had not pulled the date out of his hat (not withstanding it was a brass one :-). It was a commitment made after due study by field commanders, and their staff; the people who would be tasked to meet the commitment. Manekshaw listened to their professionally argued case.

If the Indira Gandhi and Manekshaw did not behave as they did, 1971 would, most likely, have been a disaster.

Compare that to 1962. Nehru had not listened to his Generals; had not listened for many years. The army hierarchy was disrupted, thanks to Nehru's Defence Minister. The army lacked the capability for which it was tasked. Yet shortly before hostilities broke out, while boarding a flight to Ceylon (now Sri Lanka) he told the press, that  he had asked the Army to throw throw the Chinese out. He had obviously not asked - or asked, and not listened to - the commanders who would have to do the job. 1962 still rankles.

The two episodes from modern Indian history demonstrate how to - and how not to - make a commitment. Commitment

• Cannot be dictated. It is bottom-up.
• Needs a trained team. Some factors.
• Building a trained team takes time. In the case of Manekshaw and his commanders, decades. 
• Training means formal accumulation - and dissemination - of lessons learnt from actual experience. The armed forces have many mechanisms  for this. 
• Teams must be sustainable. People leave. New members have to be inducted.
• Teams need Leadership. Management is needed. Leadership is essential.
• Needs organizational culture; a culture where reasoned dissent is encouraged; not penalized. And "Chamcha-giri" bears no fruit.

Software schedules too need commitment. Organizations that have software projects should adopt the culture of 1971. Sadly, many software companies operate with a 1962 culture.