Humility & Courage

Humility is not lack of confidence. Bravado is not courage.

I believe that Humility & Courage are essential traits for doing quality software work. The reality of software development teaches that. Refusal to learn this lesson is a root cause for poor software quality and dysfunctional teams.

Humility.
Humility means being aware that one could be wrong; that one's understanding has gaps. Humility leads us to always question our assumptions; to always put them to the test.

Defensive coding is humility. Assert statements check one's mental model of the state of execution of the code. It is accepting that one could be wrong.

Recognizing the primacy of unit tests that can be easily and frequently run, and provide appropriate coverage metrics, is humility. Adding tests that increase coverage metrics is humility.

Humility is a prerequisite for learning.

Courage.
Visually challenged persons are not be able to walk briskly. But they learn to progress by testing their way with the help of a cane. That is courage.

As software professionals we should realize that we are "visually challenged". Courage is "tapping" our way forward. The "tapping of the cane" are experiments that we must conduct to improve our understanding. These experiments have to be small steps.

Resolutely "tapping" our way to our objective is Courage.

Agile.
An Agile process is about Humility & Courage.

Why Did Some Dog Not Bark?

In an earlier post I had described as to how unit tests are "dogs that should not bark". Meaning that Unit tests run "All Green" as code is added, modified, refactored. When a unit test fails, prompt action is taken to get back to an "All Green" state.

One situation when "silent dogs" should be a serious concern is when the signature of a function is changed. That means unit test for the function is missing. That means TDD was not followed. That means a Defect in the Process.

Another situation is when a defect is discovered while inspecting the code. A little while back I had experience of that.

It was an expression that computed the radius of a circle given the length of a chord and the distance of the midpoint of the arc from the chord. High school stuff. The expression was correctly worked out in the explanatory documentation. But in the code I forgot to divide the expression by 2. I plugged the function into the module and merrily carried on. The defect was found by a member of the team that I was coaching. I asked for comments from the team. The best answer: "The dog did not bark". I had the satisfaction of knowing my coaching had been effective😊

I had not followed TDD. My Process Had been Defective. 😢

Lesson: No matter how simple the algebraic expression, use TDD to implement the function.

Validation & Verification

Validity & Verity
I am asked. "Did you have lunch today?"

I answer, "Monday."

That answer is invalid. The question has just two valid answers - "Yes" or "No".

If I give one of the valid answers, it does not mean it is the truth (verity). My answer has to be verified.

Validation checks for Validity. Verification checks for Veracity.

Valid Programs & Correct Programs
A C program that can be compiled without errors is a valid C program. Is it a correct program? By executing the program, it can be verified that the program meets its specification. It can be verified that the program is correct. Correct programs are a subset of Valid programs.

Validation Criteria & Quality
What if the compiler options are set to treat all warnings as errors? Now if there are warnings the program will not compile. The program is no longer a valid program. There is nothing to verify.

What if, to successfully check-in code to the version control system, the code must meet Complexity Metrics?

What if the code cannot be checked-in because coding standards are not met?

There is more to qualifying as valid code than just clearing compiler errors.

If you want to improve code quality, enforce stricter validation criteria.

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

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.

Scientific Method

The basis of the scientific method is recording data. To record data we need to establish metrics.  Without standard units and measurement there is no physics. Without metrics there is no software process. Without records we have only myths.

The other day I was speaking with a developer with about 8 year experience. I asked, on a software tool project, using the C programming language, with an expected size of 10K lines of code (LOC), what would be the average LOC per day. (He did not ask as to how I defined LOC. I broadly put it as the number of executable LOC - STXLN in the tool QA-C from Programming Research). The amazing answer: ~400 LOC/day!!!

In the Tools BU of Acme Technologies we constructed and renovated programming tools. My experience was a rate of 8~10 LOC/day. We had recorded data. We did not depend on myths.

Have a look at the data for the project gpsd — a GPS service daemon. A code-only size of 51,064 required 12 person-years. Assuming 22 working days/month, this works out to a rate of 16 LOC/day!

PS:  An earlier post on keeping records

Test Driven Development

For the past few months I have had to write C code. As some readers of this blog would know, for the past decade I have been preaching, or to use a more polite term - evangelizing, a great deal about software process and about coding practices. All of what I preached was from books that I read. What I read had enlightened me as to the mistakes I had when I was coding over the preceding decade.

The code has to be in C. I wanted to do test driven development. When I had tried to introduce unit testing in our compiler work at acmet, a major problem was the non-availability of a suitable C unit testing tool. This time around I came across the book Test Driven Development for Embedded C. It describes the use of CppUTest. I have gone through about half the book. That is sufficient for my present requirement. All the code that I am now writing is test driven.

A few weeks ago, I had to provide code for a small problem posed by one of our development teams. I found refactoring my code to create the needed modules much less of a problem than I had imagined. I could not have done it quite that easily had I not had the units tests. The discipline of TDD I found leads to far easier and better modularization. I could with full confidence hand over the modules to the concerned team.

For those doing embedded systems programming in C, I strongly recommend adopting the methods described in the book

What Keeps Defects Hidden?

My top five:
1. No daily build and smoke - failure to get the bad news early
2. No unit tests
3. No reviews
4. Code that is hard to understand (follow Linus Thorvald's guidelines)
5. Aggressive scheduling leading to Muri

So when code is not subjected to these it is like work-in-progress widgets inventory piling up at a machine. It is inventory piling up. 

Okay the code works fine, passes all the tests, but there is no user manual. Or it is hard to modify because it is a Bhoot Bangla (going slightly off topic see an oil rig that was one).

When we say we have shipped, did we ship a finished product or was it work-in-progress?

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) :-)

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.

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.

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.

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.

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.

Why Have an Office?

Seth Godin has a post on Goodbye to the office. For a software company the real work no longer requires an office.

An office is required for legal/taxation purposes. A company is an entity independent of its members and requires a "brick-and-mortar" address.

The office now fulfills a social role; provides a sense of belonging to a group; provides some sense of identity; as Seth says, it meets "I need some place to go".

I have practised it for some years now. And at the tools BU that I headed, we had no problem in permitting people who wanted to work from home, to do so. I am based in Noida. The tools people, except for 4 persons, were all based in Chennai. Owing to our process I had no problem in keeping track of what was happening.

I would however, like to add a caveat. Working remotely is not for everyone. It calls for a great deal of self discipline.

Project Roadmap or Project Plan?

Quite frequently I see the two terms used interchangeably. I think there is a difference.

A road map is not a plan. To use a software term: A road map is just a data structure.

To get from city A to city B by road, one consults a map to decide on means of transportation; the route to take; contingency routes; what are the other cities on the way; road conditions; refuelling stops; weather conditions; ... That does not make it a travel plan. It is when we plug in estimates of dates and estimates of travel time and estimates of stop times, and decide on preparatory measures that it becomes a travel plan.

Different travellers can have the same road map for getting from city A to city B. Yet they may have different travel plans.

A Project Roadmap just has a set of paths to desired project outcomes. It is estimates of time, and allocation of resources, that create a Project Plan.