Are You a Lean Developer?

A tourist visiting England’s Eton College asked the gardener how he got the lawns so perfect. “That’s easy,” he replied, “You just brush off the dew every morning, mow them every other day, and roll them once a week.”

“Is that all?” asked the tourist.

“Absolutely,” replied the gardener. “Do that for 500 years and you’ll have a nice lawn, too.”

Dave Thomas offers this story as an example of the powerful effect of Kaizen in his book, The Pragmatic Programmer. As Dave describes it: “Kaizen is a Japanese term that captures the concept of continuously making many small improvements. It was considered to be one of the main reasons for the dramatic gains in productivity and quality in Japanese manufacturing and was widely copied throughout the world.”

Kaizen is one of the building blocks used in Toyota’s implementation of lean production operations. Lean operation is in competition with the traditional operational approach with the former boasting fewer resources, activities, people, and inventory while yielding greater productivity, lower costs, shorter cycle times, and higher quality. It sounds too good to be true! I decided to look at the other building blocks employed by Toyota’s lean operations, and how they could relate to programming:

• Muda: Waste and inefficiency

This is the core concept of lean, and to achieve real results, you will have to get your hands dirty. Look outside the coding itself. Are you efficiently communicating the needs of the client? Are you using the best software available? Are you doing something inefficiently because you didn’t research the best way to tackle a problem? Are you overproducing?

• Kanban: A manual system that signals the need for parts or materials

The agile development process takes care of a lot of these issues. In the days of the waterfall cycle project managers clung to the waterfall method as the Bible when implementing a system. Changing a specification mid-way through demonstrated that this approach was more about the developer than the client. Times change, and regimes change. It isn’t necessary to have all the information about everything to begin. Work from a small list, and continuously show the customer what you have to get their feedback. I wish our employer offered a more closed loop about the client feedback on what you had implemented.

• Heijunka: Workload leveling

There is a penalty to varying your output production. I found it fascinating that the Japanese have integrated the concept of Takt Time into their work operation. Takt is the German word for musical meter. This is the cycle time needed in production to match the pace of production to the demand rate. Think of a real-time scheduling system. Is your environment’s “heartbeat” synchronized so that you are getting requirements as you need them? Is your quality assurance team reviewing code you just checked in? Are you getting instant feedback? A rhythm will generate more efficiency than switching contexts, and varying workloads.

• Kaizen: Continuous improvement of the system

Tackle your TODOs and HACK HACK HACKS, and don’t be afraid to change code just because of the impact on other code. Specs change, and code tends to become increasingly entropic. Fix the problems instead of patching them. Backport your newfound knowledge into older code bases when there is a benefit to doing so. Don’t waste vast amounts of money on consultants!

• Jidoka: Quality at the source

Quality is a tough issue in software. Some people rely on tests, others on peer review, and most on both. Strike a balance between coding your project and testing your product. Don’t test so much that it is wasteful and inefficient – aim for a 1:1 ration with coding and testing. After having worked with Cucumber, I can’t say that the time trade-off is worth the coverage provided. Stick with fast test suites (like Rspec) and manual confirmation by clicking around.

• Poka-yoke: Safeguards built into a process to reduce errors

Working in a framework with a community centered on common conventions is probably the best way to tackle safeguarding yourself. The Rails MVC approach is a time tested software design, and usually when something is hard to do, its because you are going out it incorrectly. Another concept that comes to mind is code smell. Code smell isn’t specific to Ruby, but rather is a common convention among most programming languages.

I think that it would be an interesting experiment to convert a Rails shop into a lean operations center just to see what happens. As you can see above, many of the aims of Ruby on Rails, and the agile method pair quite nicely with the lean operational style. What are your thoughts?