ZAMM-1

I mentioned in my previous post, I am going to make a series of posts about "Zen and The Art of Motorcycle Maintenance" (ZAMM).

Before I post about specific passages that resonated with me, I want to first talk about my relationship with the book.

I first read the book about 20 odd years ago. After that I have re-read it a couple of times. Never the same copy. I confess to being guilty of having given it to (forced it on?) people I have known, to read. I really missed the last one that went missing. It had lots of notes, and highlighting, and a personal index. Then on 22nd Dec last year (I remember the date as I was at the airport to receive my son and his family), I came across the 25th anniversary edition. I promptly purchased it from the Kindle store. I am happy that I did.

The first time I bought the book was because I was fascinated by the title. I was quite adept at stripping down my Lambretta scooter and putting it together again. Never at the level where I did my own welding or machining, like the author; I wished I had the gumption to do it. (The book has a lot to say about gumption. I relate to it totally.)

I was also mildly interested in Zen

Here are a couple of things that I believe about the book:
1. It is one of two books, without reading which, the education of an electronics - or software - engineer is not complete. The other book is, Tracy Kidder's "The Soul of a New Machine". (I still have my copy:-)
2. The book was first published in 1974. That was just after the Oil-Shock of 1973. Fuel efficient Japanese cars started making inroads into the American market. The consumer electronics industry was finished off. Americans could not believe that the Japanese could produce high quality goods at the prices they did. Japanese industry was studied. Japanese methods like Quality Circles were adopted. Nothing worked. Till finally it was established that Japanese practices required Japanese civilizational values. (See the books about Toyota authored by Jeffrey Liker). I find it prescient of the author that in ZAMM, he ascribes the problems of American society in general, and American industry in particular, to civilizational values. And since Western, and hence American, civilizational values derive from ancient Greece, he traces the problem to Aristotle. Very interesting.

Pin Factory Revisted

A while back I had posted about software work and the pin factory. As that post makes out, I am no admirer of specialization.
  
Yesterday I finished reading "Zen and the Art of Motorcycle Maintenance". The sub-title of the book is An Inquiry into Values (Note: Italics and underline are mine). The edition is the Twenty-fifth Anniversary Edition.

Quote from the book:

"Arete implies a respect for the wholeness of life, and a consequent dislike of specialization. It implies a contempt for efficiency - or rather a much higher idea of efficiency, an efficiency which exists not in one department of life but in life itself."

In an earlier paragraph the author, quoting Kitto, an authority on ancient Greece, says  arete to the ancient Greeks simply meant excellence.

PS: Prof. Prisig could just as well be talking of software instead of Motorcycles. I hope to post more on the subject - and the book.

User Interface

What is the user interface if you are writing C code?

As people who have worked with me know, I am a fanatic (I suppose evangelist and fanatic are synonyms) for source code documentation. In all the time that I evangelized, I do not think that I ever mentioned header files.

And it is in the header file that the user interface of a C module resides.

I recently "shipped" some re-factored code to one of our teams. I shipped a second version after about a week. The revised version. changed the behaviour to make it more in line with what would be expected behaviour in the real world. Prompt came the response that no change was noticed in the files.

Going through the .c files, to locate the changes would have been difficult. WinDiff of course would have showed the difference. But it would still be confusing. What was required of my customer was to go thru the .h files. There was only one .h file that was modified. In that the signature of just one function was altered. The comments in the .h file explained the WHAT and the WHY of the change.

Unfortunately, header files are not viewed as the user interface. It should contain all the information required for the" customer" of module to use the module. The "customer" should not have to go thru the .c file. That is for maintainers.

Was I blameless? No. I missed out on a standard practice - a Change Log.

A super set of my experience, described above, is described in API Documentation.

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

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.

After Action Reports

Most armed forces worth the name have "After Action Reports" (AAR).

All learning organizations have to have a similar practice, done at regular intervals, as part of their process. A Causal Analysis Meeting, done after every defect fix, was once such practice that we had at acmet.

Recently I came across a misapplication of the term.

A pilot run had some problems. These were identified. Corrections are to be be made for the next lot to be produced.

This is defect correction. An AAR is about defect prevention. For that to happen root causes need to be identified. Taichi Ohno's 5-Whys need to be asked. It needs deliberation

Is Science Just About Prediction?

In a not so recent post Seth Godin asks "are you a scientist?" Scientists, according to him make predictions. And get it right.

That is SO wrong.

Science is about observing phenomena, making hypotheses, testing hypotheses through experiments, and then making a theory that one can use to make predictions. And then not being surprised if the predictions are off, but go back to making hypotheses and experimenting