Management Objectives & Coder Objectives

Technical Debt.
Management has business goals - both short term and long term. The two need to be balanced. That is the art of management. Excessive focus on one, or the other, will lead to failure. The short term, by its very nature grabs attention; in most cases to the detriment of the long term. In software development this leads to the taking on of Technical Debt.

Consequences.
As Technical Debt piles up the code becomes increasingly fragile. Fixing one defect introduces other defects. Feature addition becomes a nightmare. Customers become increasingly dissatisfied. The brand erodes.

Causes.
Technical Debt 101 explains the factors that cause technical debt. I strongly recommend reading the article.

Concentrating on today's fires is exciting. Trouble is, the excitement is paid for by taking on technical debt. In this, management have very "willing allies" - the Coders. What are a coder's objectives? The most important are:

1. Improve job market prospects. Hence acquire skills, knowledge.
2. Ensure that they are not easily replaceable by their current employer. The higher the technical debt the greater the job security.

Practices required to prevent buildup of technical debt do not figure in the objectives of most coders. In the rare case that it does, management, by their actions, ensure that it is soon given up.

Software Exorcism is a book that deals with Technical Debt. The book, as it's title says, is about getting rid of the "evil spirits" that can take up residence in software. An evil spirit, in Hindustani, is called Bhoot. Once evil spirits take up residence the software becomes what, in Hindustani, is called a Bhoot Bangla - a Haunted House. Now there is a vested interest in not exorcising the evil spirits.

Exorcism: First Step.
Technical Debt must be managed. Managing anything - whether diabetes, or sports teams, or whatever - requires metrics. Managing financial debt requires financial metrics. Managing technical debt requires technical debt metrics. Managing technical debt will ensure a development process that,

1. Prevents unhealthy build up of Technical Debt. 
2. Takes corrective action to reduce it to defined acceptable levels.

Being In The Zone

Coding can be exciting. Especially when you are in the flow - in the zone. That's why we like to code. The total absorption in the task, I believe, is the same as being in a state of meditation.

I should know. Why else would I be coding in my seventies?

However, as with anything that we enjoy doing we must learn to do it in a disciplined manner.

In the zone one needs the discipline to :

1. Write the Executable Specification before implementing the code that it will test.
2. Use the idioms of team's coding standard. 
3. Spend time on thinking up names that convey the intention/purpose/responsibility of the files, objects, structures, functions, and variables.
4. Commit frequently to the version control system (I advocate using Git). Do a diff of the source files with the earlier commit. Document the reason for the changes in the commit log.
5. Refactor ruthlessly.

The discipline has to be practiced when in the zone. 

Easier said than done. I should know. Six-Pack Abs need discipline 😊

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?

Sherlock Holmes & Software Engineering

In an earlier post I had mentioned "Pratyaksha Pramana" and "Anuman Pramana" and how these constitute the scientific method. And that "Shabda Pramana", contrary to what Justice Katju seems to think, cannot be part of the scientific method.

Sherlock’s Scientific Method

Very good illustrations of these are to be found in Arthur Conan Doyle’s, Sherlock Holmes mysteries. If you have not read them, I suggest you read a couple of them. If you have read them, it would have been a long time ago; I urge you to reread them.

The primary Pratyaksha Pramana is of course the crime. That is the phenomena for which a sequence of verifiable actions needs to be established.

Holmes then uses his acute powers of observation to establish a secondary set of Pratyaksha Pramana.  That enables him to deduce facts (Anuman Pramana) that appear incredible till Holmes describes his observations and the deductive steps. Holmes description of the deductive steps, to my mind, is equivalent to the presentation of a mathematical proof for peer review (not that Holmes would consider any of his interlocutors his peer).

Note it is not just “Pratyaksha Pramana” but acute powers of “Pratyaksha Pramana”. Acute observation is not sufficient. As Holmes says, “Having gathered these facts, Watson, I smoked several pipes over them, trying to separate those which were crucial from others which were merely incidental.” (The Crooked Man). Holmes emphatically expresses the primacy of data: “Data! Data! Data!” he cried impatiently, “I can’t make bricks without clay.” (From The Adventure of The Copper Beeches). If it is not relevant, it is not data. Needless to say, deciding what is relevant is error prone. The only way to reduce it is by regular practice of the scientific method.

Holmes’s “Anumana Pramana” are always subjected to test. In some cases the test consists of simply presenting the deductions to the person involved for their confirmation. In other cases Holmes sets up experiments. As for example, in the “The Adventure of the Beryl Coronet” he dons a disguise to get confirmatory evidence, in the form of the suspect’s used boots, from the suspect’s valet.

Why is Sherlock relevant to the practice of Software? Because, defect rectification is detective work; locating performance bottle-necks is detective work.

Cyber World Detective Work

“The Cuckoo's Egg” is the true story of how the author, Clifford Stoll, uncovered a cyber-attack by the KGB . The “Pratyaksha Pramana” was a 75 cent shortfall in the total billed computer time at a research facility! The Anuman Pramanas and the experiments (tests/traps) setup to verify those and ultimately catch the hackers makes for thrilling reading. 

Clifford Stoll is a scientist - an astronomer.

Dogs That Should Not Bark

The absence of "Pratyaksha Pramana" (call it "A-Pratyaksha Pramana") could also be valid observation. In the “Silver Blaze” the following conversation illustrates this:

Gregory (Scotland Yard detective): "Is there any other point to which you would wish to draw my attention?"

Holmes: "To the curious incident of the dog in the night-time."

Gregory: "The dog did nothing in the night-time."

Holmes: "That was the curious incident."

Assertions and Unit Tests are “dogs that should not bark”. Assertions are hypotheses (Anumana) as to what the internal state of the code should be (or should not be). Unit tests are an anumana (hypotheses) of what a unit of code will do for a given set of inputs. If an assertion dog barks it indicates something is not as expected. If they do not bark they provide "A-Pratyaksha Pramana" that the code behavior (anumana) is as expected – or to coin a words, as “anumana-ed”. However, it must be checked that the dogs can bark! The first step in Test Driven Development is to write a unit test that fails. Only then is functionality written that will silence the dog.

Apple's Software Process

Apparently Apple's Software Process has some problems. See Michael Barr's post.

Ah well! Apple is famed for cool products. Can quality processes qualify as cool? Well ... :-)

Specification, Prototypes, Evolutionary Design

I think this one  by Seth is not quite correct.

One, the Taj Mahal is not a "big white marble house". It is not a house. It is a mausoleum.

Two, there were plenty of past works on which the development could have been based. His great-grand father, Humayun's tomb, in Delhi, could easily have served as a prototype - except for being in red sandstone. But then when Humayun died, the Mughal empire was not what it was in Shah Jehan's time!

The Taj Mahal is built on proven architectural principles. It is a design that has evolved.

The best specs are prototypes. And Shah Jehan would have seen plenty of those, as would have his architects.

Message: build your software on sound proven design principles. Successful designs - whether biological, architectural, or software - are evolutionary.

TDD & JIT

A while back (actually quite a while back :-) I did a couple of posts on Just In Time (JIT) and the software process.

In manufacturing, JIT exposes problems. Early discovery means action can be taken to prevent costly systemic failures when conditions change, or are no longer favorable. Thus any part of the process which helps in getting the bad news early is a JIT process.

I am currently reading Test Driven Development for Embedded C.

Test Driven Development (TDD) require tests to be written first. They do not have to be complete. Nor are they written on tablets of stone. But they do have to be written before writing code. And code does not have to wait till all the tests are written. Write one small test. Code a dummy implementation that should fail. Watch the test fail. Then write just enough code for the test to pass. If a "What-if" (or, as some developers in the Tools BU of acmet called them - "Please Consider") strikes you - as inevitably it will - first encapsulate it in a test. Then - and only then - write the code. Keep a note. But no coding.

Coding without the tests is building inventory.

And it is not just that one test that has just been coded that is tested for. All tests must pass every time a test is done. That necessitates automated builds and test harnesses. So if anything breaks the bad news is known straight away.

TDD is JIT.

Again on Just In Time

Just in time does not mean waiting till the last moment. Just In Time is to prevent waste. The proverb - "Haste makes waste" - is equally true. Unhurried delivery of worthwhile work is what is required to deliver quality.  

"If I Only Changed The Software ...."

Recently I finished reading the book, "If I Only Changed The Software, Why Is The Phone On Fire?", by Lisa Simone. The book narrates the story of a team developing embedded software.

What Resonated (a very small selection)

1.  Li Mei’s systematic recording of lessons learned and Josie’s insistence on dissemination (page 262-263). That is what creates a learning organization. While an oral tradition is important, it is only documents that transcend space and time.

2.  Pg 261. “ … as long as you put a descriptive comment block above it…”

3.  Pg 261. “... not well architected … you have to wonder what other time bombs …” In other words a Bhoot Bangla

4.  Pg2. “… customer, who pulled one out of the box, turned it on and found the failure.” This is what I call RM’s extension to Murphy’s Law: If anything can fail, it will. And it will happen when the customer is watching.

5.  Pg 240. “… with out realizing there was another one in a different function?” Our Japanese customer taught us this was SUHEI TENKAI.

6.  Pg 141. “The sense of hearing …” Many years ago, when I was young engineering officer in the Indian Air Force, I remember a wizened Warrant Officer telling me, “Sir, these test equipment will tell you a lot, but your five senses will give you your first indication that something is wrong. And in most cases they also tell you what is wrong.” Of course nothing known as embedded those days no digital too (in India).

A must read for embedded software developers. I hope the book comes out in an inexpensive Indian edition.

Just In Time vs Well In Time

This a scene common enough in most examination halls in India.

There are some who keep writing till the invigilator comes and yanks the answer book from them.

There are others who pace themselves and spend the last 30 mins of the 3 hour examination (16% of the "development" time), revising (reviewing) their work.

What about all-night cramming before the exam vs. study spread through the semester?

Which one does your process look like?

Which one would you like it to look like?

Just In Time is easy to misapply.

Coding Productivity

Some days back Ramy sent me  this link. A some what in-extenso quote from the article:

“… To the contrary, they fully understand that few things are more foolish, dangerous and pathologically counterproductive than superficial productivity measures. Great coders don't just write great code, they grasp the essence of problems in ways that makes their code architectures clean, accessible and maintainable. The code not only works, other coders — perhaps less talented — can safely and creatively build on it, with it and for it.

Their code costs less to support and evolve even as it invites and facilitates new value creation. Only the technically naive and economically inept see code as a software deliverable that programmers should produce on time, on budget and on spec. People who really know what they're doing appreciate the lifecycle and ecosystem economics of their efforts."

Note: The emphasis in the above is mine.

 I believe that that was at the core of our development process at acmet's Tools BU.

An earlier post on  measuring software productivity is relevant to the subject.

Code Reviews

Seth Godin has a recent post which I think is applicable to software artifacts.

Code and documentation will be required to be understood by developers long after the original authors have gone. It is important that reviewers "share their confusions" rather than "improving" the code.

Quality Control and Quality Assuarance

India Software Brief group on LinkedIn has a post on protection from bad software. The actions to be taken by an outsourcer (the one getting the software developed) are all necessary acceptance checks. The problem is what happens when the acceptance checks fail? Sure, reject the product but what happens to rolling out the services that depend on getting this software?

Acceptance checks can provide assurance that bad software does not get accepted. It does not provide assurance that good software will be delivered.

Far better to check the outsoursee's processes and be assured that the final acceptance checks will not turn up serious deficiencies or defects. An incremental model of development, with actual functioning code delivered would give a better estimate of the progress. This, of course, requires that the outsourcer put resources to test each increment and give feedback.

A while back I posted my views about QA and QC. The outsourcer must verify the QA processes and, by providing feedback on each increment, become part of QC. I suspect the root cause of all outsourcing horror stories lie in not doing this.

What is Redaction?

I was browsing through Michael Barr's post about the unintended acceleration problem in Toyota cars. He uses the term redaction/redacted at a number of places. It is a word that I had never come across. He explains the term in the second paragraph of his post but since I wanted to get to the details of likely defects in Toyota's software, I missed it. A Google look up led me to believe it meant a frame or a side-bar that one commonly finds in article and books. (Incidentally Hindu's series on WikiLeaks concerning India also mentions redaction by the Indian Embassy of the Indian Ambassador's statement.)

I downloaded Appendix A  to NASA's  report from NHTSA's site. When first I saw the document on the screen I thought there was some problem with my internet connection. It took me a couple of seconds to realize that those black boxes were redaction - plain and simple censoring. To me that appears very suspicious.

I have browsed through the post mentioned above and the subsequent post. Both posts deserve study. I strongly urge all those concerned with quality of large embedded software to study the posts.

Will Social Networking Tools Help?

The December, 2010, issue of Entrepreneur has Vivek Paul on the cover. The cover story talks of Kinetic Glue the venture that he has started.

The features of the products, I think, will definitely add to productivity - provided if it is used. The armed forces have a saying, "A machine is only as good as the man behind the machine". It is this man (and increasingly woman)-behind-the-machine - their training, motivation, ethos, value - that determine effictiveness.

So too with any tool. It needs people with the appropriate culture. A collaboration tool can only help if there is a culture of collaboration. Tools cannot break down silos. If the correct culture is built and nurtured, and contrary behavior robustly discouraged, will silos break down.

Lacking a culture that discourages silos, the tools will be ineffective. Result: The tool will get a back name.

Before selling the tool should not Kinetic Glue conduct an analysis of the culture and advise the company about changing the culture? I think so. I doubt if Kinetic Glue, or Vivek Paul, think so :-(

If the correct culture is not in place should Kinetic Glue sell them their tool? They should not. I am sure Kinetic Glue will sell it.

It comes down to defining who is your prospective customer; and who is not - segmentation.

To all readers of this blog:

A High Quality, Low Defect, Sustainable work year;

May you spot and quickly fix Broken Windows; 

May you spot and chase away all Wolves-in-Sheep clothing;

Happy New Year!

Oversimplifying

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

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

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.

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.