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

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?

Just In Time for Software

As a readers of this blog would know, I am a great admirer of the Toyota's quality process. I believe that the processes are applicable to software development and renovation.

What puzzled me for a long time was this: How can Just In Time (JIT) apply to software? Software production does not depend upon inventory. To make the second copy of a software product does not require another set of parts to be procured.

Then one day I was talking to my son Vijay, who is a supply chain guy, about Just In Time. He said, "Daddy, Just In Time is about showing up problems in the process".

That was it. I had been looking at the mechanism, not the purpose it was meant to serve.

A software process that exposes defects early is a JIT process.

Which of course begs the question: What is it that keeps defects hidden?