Kipling's Advice for Project Managers

I keep six honest serving men
(They taught me all I knew);
Their names are What, and Why and When;
and How and Where and Who.

– Rudyard Kipling (1865-1936).

Any plan must

1. Set out the objective - the "What". 
2. Explain the reason - the "Why".  
3. Specify the steps that are to be executed - the "How".
4. Specify time sequence for execution - the "When".
5. Specify the place, or the objects, where, or on which, the steps are to be completed - the "Where".
6. Specify the persons responsible for the execution of the steps- the "Who".

Come to think of it, source code documentation too, with the possible exception of #6, should have the same information.

Specifications & Unit Tests

In my preceding post I said that writing requirements & specifications must precede the writing of code and they must be written in the source file. Stands to reason. If code has to be written, it must be for a purpose. The purpose must be known before writing the code that is expected to meet the purpose. Therefore, it can - and should - be recorded before coding.

But specifications, instead of being entered as documentation in source files, can be put down in far more useful form. They can be recorded as Executable Specifications. What are executable specifications? They are Unit Tests. Watch this exposition by Misko Hevery (from ~17:28 till ~ 24:00) for how to write Executable Specifications. BTW, the complete video is worth watching.

Coders Write Specifications

Coders write code. Should they not write down specifications like a darzi? Let me describe an example.

I go to a developer and say, "I want a routine that gives me the roots of a quadratic." (user requirement).

In less than an hour I get an executable "quadratic.exe". The developer asks me to run it. I get prompt a prompt: "Please enter a: ". The developer informs me what is "a" and also what the following two inputs "b" & "c" are.

       I enter 0 for "a" and 1 for "b" and "c". I get a divide by zero error. I am expecting the result to be       -1 (x + 1 = 0)
       I enter 1 for a, 0 for b, and 1 for c. I expect to get imaginary 1 (j1). I get a NAN.
       I enter 1 for a, 0 for b, and -2 for c. I expect 1.414. I get 1.414213
       ....

I did not get what I wanted. Should I be disappointed? No. What I got was a prototype.

Prototypes are very useful. They help to refine user requirements and specifications. I do that now. Also, I add that I require to have  a function that will compute the roots and return it in a structure. I then define the structure for the developer.

The developer should now put the requirement and specifications in the function header. And it should be done before making any changes to the source code. As a matter of fact there should have been a header for the prototype code.

Function headers, and file headers are not comments. Comments are post action. Comments are made by Commentators.

Function headers, and file headers are requirements and specifications. They precede the action. Acts need to have a purpose; a desired result. They need to be performed when required preconditions are met.

Cricketing example: Dhoni (or Virat) sees a ball coming at him. It meets the preconditions for a six. He knows the Specifications for the action he has to take. He takes the action. The result follows. The commentators watch the result and pass Comments.

Commentators pass Comments. Coders write Specifications.

Unexploited Value of the CMM

Note:

• I use CMM to refer to both the CMM and its successor the CMMI. 
• What  I have to say about the CMM is also applicable to other process related classification tools e.g. SPICE.

As Wikipedia describes it, the CMM started out as a tool to assess vendors for government (US) software contracts. This, I consider, has led to a distorted view of the CMM tool.

The Distortion

• Software companies, view the CMM rating as merely a marketing aid. 
• As a result, the objective becomes getting certified - not process change. Any process change is just for the benefit of certification inspectors. It is window dressing. The actual process remains unchanged. There is a saying in Hindustani which accurately describes this behavior, "An elephant has two sets of teeth; One for display, another for eating". It is what some (?) of our garment exporters used to do; sample lots used one process, shipment lots used a "practical" process. Garment exporters could sell their rejects in the local market. Software exporters do not have that option.

My Thesis.

• The CMM is a tool for top management, just as much as a balance sheet is.
• Balance sheets too are subject to window dressing. However, top management - unless they are drinking their own kool-aid - would be fully aware of the true situation.

What is The CMM?
I will take the terms in reverse order.

• Model (the 2nd M). The statistician Box said, "All models are false; some are useful."
• False, in the sense that no model captures the entirety of the subject. 
• Useful in the sense that relevant characteristics are captured.
• Relevance is determined by the problem/application/domain. Or, to be tautological, usefulness is determined by use.
• Box was a statistician. Statisticians deal in numbers. No metrics; No models.
• Maturity. 
• I take this as the analogue of what it means for a human to exhibit mature behavior. What is mature human behavior? It is the opposite of immature behavior. It is childish behavior (note: childish and childlike are not the same). The main characteristics of mature behavior are:
• Consistency.
• Predictability.
• Calibrated response.
• Awareness of consequences.
• Low variance of process metrics indicates higher maturity. That is what Six-Sigma processes are about.
• Capability. 
• The Model mentioned above models Capability. As mentioned, modelling requires metrics.
• The facets for which the metrics are required:
• Domain knowledge
• Code
• Size
• Quality metrics
• Project Management. 
• On-time delivery
• Responsiveness to change
• Time to fix defects
• Administrative & Financial.
• Personnel
• Infrastructure
• Project resources
• Metrics mean making measurement. That means demonstrated performance - not imagined performance.

Both process capability, and process variability (maturity), are important. 

Relevance to Management.

• Project Management is about making and keeping commitments.
• Commitments require estimating future performance.
• Estimates have necessarily to be based on the past - the demonstrated capability.
• The reliability of estimates is indicated by the variance of previous differences between estimates and actual performance - the demonstrated maturity. 

Action.

• Software organizations must, on a regular basis, check the health of their process. The CMM is an instrument for performing the check.
• A regular CMM check for the process is as necessary as a regular medical check-up for people.
• Performing a regular CMM check should be the top task of the QA team.
• The report should have the attention of the CEO and CTO

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.