BasVodde

I wrote an Amazon review of a new book called "Birth of Lean". You can find the amazon entry here

I copied the review on this blog. Think its worth reading for people interested in Lean:

--------------------

The Birth of Lean is a collection of six interviews with people who influences the creation of the Toyota Production System; what became later known as lean manufacturing and lean thinking. The book is a translation of the Japanese book which was published in 2001. This book is full of stories, insights and nuggets of knowledge, but it is not for people who are new to lean. The book assumes you already have an understanding of lean and the TPS.

The first interview is with Taiichi Ohno, the father of the TPS. Its a three hour interview, but was done without tape recorder, so it is a summary of the notes written by the interviewer. It makes the interview somewhat short, but still contains interesting and little known facts about how the TPS was created (for example, having to wait three years before he could introduce kanban because of the "tax people")

The second interview is called "What I Learned from Taiichi Ohno" by Michikazu Tanaka who worked close together with Ohno when he was at Daihatsu. This interview is my personal favorite one as it contains a huge amount of Ohno-isms (short stories about Taiichi Ohno). It is full of insights about TPS and how Ohno taught it to other people.

The third interview is with Kikuo Suzumura who worked under Ohno and was one of the people who did the real early implementation of these ideas and perhaps one of the secret inventors of many of the TPS techniques. He describes all the problems he encountered over time and what kind of innovative solutions they came up with. This interview is by far the most technical one.

The fourth interview is with Kaneyoshi Kusunoki who worked under Ohno and is one of the co-authors of the first English-language paper about the TPS (which is reprinted in this book). The interview itself is short, but insightful. The paper is surprisingly well-written and I wonder why it hasn't been reprinted in the earlier lean materials.

The fifth interview is with Masao Nemoto who was the major force behind the TQC implementation inside Toyota. Much talk about Toyota is about the TPS, but the Toyota TQC is rarely mentioned (even though they won the Deming prize twice). Nemoto talks about things such as the evolution of policy deployment and about management of QC circles. He looks at Toyota from a slightly different perspective as the others, which makes his interview very interesting.

The last interview is Eji Toyoda, who in senior management positions during the development of the TPS and the deployment of TQC. There are actually two interviews where Eji talks about the strategic decisions made by Toyota during his period. His humbleness is especially striking.

All in all, this is a book full of little insights in Toyota and Lean which makes it well worth reading it. However this is not a beginner book! The whole book assumes that you already know Lean and TPS well. So, if you want to know more about Lean... you probably first want to look into "Lean Thinking" or "The Toyota Way." If you already got a deeper understanding of the topic then this is a book you certainly do not want to miss.

An interesting post

Last weeks I've been working on some legacy code. Most of it has been refactoring, but we rewrote a couple of modules to we test-drove these... of course. The TDD cycle is so slow that it made me realize a technique I'm using... but wasn't aware of. I'll simply call it "predictions" :) It speeds up your TDD cycle a lot.

If you are developing multi-player games then you'll have to deal with the network latency. The graphics on your screen and the behavior of the players is faster than the packages on the network. That means... if you would draw a player only after you got its exact location over the network... then your gameplay might turn out to be crap. One technique that has been used for years is "prediction." The client will predict where the objects are located... then made adjustments based on the real packages coming in. Most of the predictions can be reasonable accurate and that will speed up your game and save your gameplay.

TDD in C often has a slow cycle. The test of the particular component I worked on last week ran in 7 seconds (down from 15 after some setup refactoring). However, the linking took perhaps also 5 seconds. A rebuild would take about 10 minutes. Having incremental compilation, most of the time we just edit a couple modules, so the compilation of that was perhaps 2-3 seconds. Thus... for an incremental change.. total cycle time about 20 seconds. For a header change (with includes being messed up as they were.. being legacy) about 10 minutes. Such a cycle will bore any TDD-er.

So, if you are in such an environment... you might want to use "prediction." The information about were we are will be delayed due to compiler latency. So to increase our gameplay, we'll predict were we are. We'll turn on the compiler, predict the tests to be red and start implementing it. The compilation/linking and test run will happen in the background. When they are finished, we received the information we needed to make our correction. Most of the time our predictions are pretty good. However, sometimes we start coding in the wrong direction and we'll need to undo our changes and get back to the reality... the tests. We'll predict about 1 minute in the future and that way make our TDD cycle fast and it saves the gameplay.

Test-driving with prediction makes TDD in C almost like TDD in Java (missing most of the automated refactoring, but the CDT ones help a bit).

Of course... we do need to be careful that the prediction doesn't move us away from TDD. We don't want to speculate too far in the future. We certainly don't want to implement functionality that we don't have a test for. We only want to predict the outcome of the compiling/linking cycle and the test run.

Craig and me changed the "top 10 organizational impediments" in an article and published it on ScrumAlliance. We added two points of ourselves. You can find it here.

In Bangalore, on my way back to Singapore. It is another late night flight. I hate them and consider the new Bangalore airports to be perhaps one of the least interesting airports in the world. Still an hour before my flight leave, hope I can stay awake.


Last weeks I've been able to do some more development. Worked on some legacy code, refactored it mainly and fixed some broken test (or broke some test that were accidentally passing). Also had some time to work more on the CppUTest memory leak detection part for C. Fixed a couple of interesting bugs that didn't happen until I started working on multiple platforms. Also implemented the realloc, which turned out to the harder than I expected (I expected I would be done in 5 minutes). I think soon we'll be able to do a new release, waiting for James his results on porting to IAR. That sounds like a lot of fun.

Next week working the whole week with Steven and then off to China again coaching some teams there. Looking forward to that, though March is still pretty cold in China :(

Oh well, this blog post kept me awake for 10 more minutes, now I need to find something else to keep me awake.

Michael Feathers came up with an excellent list of must-read papers from programmers (he is bored, his head it too heavy).

You can find it here:

http://michaelfeathers.tumblr.com/post/81489281/10-papers-every-programmer-should-read-at-least-twice


There were some papers I didn't know, but also some papers I'd think would be missing, such as Dijkstas "The Humble Programmer". Still, a nice list. (not he can go back to watching Idols)

------------------

Copied Michaels list for those who cannot access his blog:

1. ‘On the criteria to be used in decomposing systems into modules’ - David Parnas
2. ‘A Note On Distributed Computing’ - Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall
3. ‘The Next 700 Programming Languages’ - P. J. Landin
4. ‘Can Programming Be Liberated from the von Neumann Style?’ - John Backus
5. ‘Reflections on Trusting Trust’ - Ken Thompson
6. ‘Lisp: Good News, Bad News, How to Win Big’ - Richard Gabriel
7. ‘An experimental evaluation of the assumption of independence in multiversion programming’ - John Knight and Nancy Leveson
8. ‘Arguments and Results’ - James Noble
9. ‘A Laboratory For Teaching Object-Oriented Thinking’ - Kent Beck, Ward Cunningham
10. ‘Programming as an Experience: the inspiration for Self’ - David Ungar, Randall B. Smith

Scrumban in a small book by Corey Ladas self-published by lulu.com. The name is somewhat confusing since most of the book is about setting up a SW Kanban system and only a couple of pages are about scrumban (the hybrid between kanban and scrum).

Scrumban is an rather interesting book. I loved reading it and I think that it is an important contribution to software development. I say this even though I disagree with perhaps half of the book -- or at least consider them to be build upon shaky assumptions. Whether that is true or not, Corey delivers an interesting way of thinking about software development and a good basis for further discussion and improvement.

The book describes applying lean manufacturing techniques to software development. Unlike earlier lean material, it takes lean techniques and maps them to software on a very concrete level. The main technique taken from lean is the kanban technique for scheduling work. The book starts by describing "ideal" states of how software development should look like when mapping lean ideas to software. After that, it takes a couple of steps back and gradually builds up a kanban system by discussing one improvement to the system at the time. Halfway the book it describes how you can start applying kanban within your Scrum implementation and gradually improve it until its not scrum anymore, but kanban.

The end of the book discusses some more 'advanced' techniques like handling bugs, improving handovers, prioritizing backlogs and ... silver bullets :)

Corey tries to find a balance between traditional learnings and agile learnings. He tried to balance advantages of specialization with flexibility of generalization. He also tried to define a way of defining processes where Scrum basically just says "go and figure it out for yourself." This approach brings an interesting perspective to development processes.

So, what didn't I like? The book seems to assume that there is such a thing as a perfect workflow for software development. It even goes so far to suggest that this perfect workflow looks like the V-Model. If thats not bad enough yet, it suggests that XP is a "modern implementation of the V-Model." Here I start to feel somewhat uncomfortable. Why? A good team, IMHO, switches between the activities of software development constantly, within minutes. Work doesn't flow from one activity in another activity. Thats a workflow does doesn't fit in development, but has been artificially put over it. I would call it far from ideal, however, the V-Model workflow assumptions seem to run pretty deep in the book.

I loved the discussions on specialization and generalization. However, I'd stress domain-based specialization over activity-based specialization. Though, that doesn't seem to be covered much, except in a small part on scaling, but here it suggests to scale via component teams...

Another interesting thought that made me uncomfortable is the idea that there is such a thing as "in-control production" and special/common causes within that. To me, it feels like a manufacturing assumption within product development. Though Corey does cover these assumptions and makes great points about how to control variability, I'm not sure if it is a good thing to do.

All in all, the book gave me interesting thoughts and I might even be experimenting with some of them! I would NOT recommend reading the book when you are fairly new to agile development. The book assumes a pretty good understanding of certain concepts. However, if you want a different view on agile development and some different ideas, I would suggest reading this book. It will almost certainly contain some new ideas which makes the book worth reading.

Thanks to Corey for writing this small and interesting book.

The book is available here.

I moved odd-e.com and my blog to a new server. The old user names should still be working, but please let me know if you experience any problems.

Bas (in San Francisco right now)

Finally. Today I ran to the Fedex to grab my package from them. I just came back to Singapore and hadn't been here for 3 weeks. Last time, they destroyed my package. Didn't want that to happen this time because...

Its my own book! Finally the first one is finished and printed. It was quite an effort to get it out, but now its done! And the effort is over... oh no... its on continuing the second one! If that one is finished, then maybe there is a rest.

It looks pretty good!

Then you must be interested in xUnit shoes! They are available here