TDD is Kanban For Code

Kent Beck had an interesting blog post the other day in which he proposes that TDD is like Kanban for code. It’s an interesting mental model, and I find I like it. Kanban speaks to the idea of a consistent, uninterrupted value stream, and the removal of waste from that process. This concept maps to test driven development quite nicely; in step one, value enters the flow in the form of a failing test; next the value is built in the form of making the test pass, and finally, we refactor.

It’s Kent’s notion of the last part, —the refactoring— that I disagree with. He said, “From the kanban perspective, though, post-success refactoring is over-production, the worst of the seven wastes of the Toyota Production System.” Here I have to disagree. I believe that the refactoring doesn’t constitute waste at all, but is an essential part of the TDD/Kanban-ish value stream.

Once a Camry rolls off the assembly line at the Toyota plant, the Kanban value stream is still far from ended. To simply let the finished cars pile up at the factory would certainly be a huge waste. Without delivery of finished vehicles to the marketplace, all efficiency gains throughout the rest of the factory are pretty much moot.

I see refactoring as being similar to delivering finished cars to the dealer: I think it helps if you think not of delivering simply source code, but of delivering business value. Toyota knows that their job is not merely to build cars, but sell them. To continue coding without continuously refactoring is akin to piling up finished cars at the factory. In both cases the value stream becomes clogged, resulting in slowdowns, undelivered value, and even breakage of existing finished work.

Refactoring isn’t overproduction, it’s simply the tail end of the TDD value stream. Like every other part of the value stream, it needs to run smoothly and consistently so as not to become a bottleneck.