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.  

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?