Is writing software more like manufacturing cookies or more like designing cookie cutters? It’s easy to wish that we could develop software like a factory stamps out cookies, but software has a design or creation element that is missing in that analogy.
But there are similarities: software is developed in stages, it is created in a process amenable to change, and it’s developed in a team. Lean manufacturing is a different approach than a traditional assembly line, and offers some lessons for software development.
Let’s look at a traditional assembly line:
Visualize the first person as transforming raw materials (not shown) to A objects, which are passed down the line to someone who converts them to D’s, then C’s, then T’s.
Kent Beck has pointed out that we can think of “undeployed decisions” as the inventory in software. If we think of A/D/C/T as Analysis, Design, Code, and Test, we have here a situation where the analysts are a bit ahead, the programmers are stuck waiting for some design, and the testers (with that pile of Code sitting around) are working on a backlog. (And when they communicate with the programmers, it’s about something that was done a while ago.)
This paper very nicely brings the lessons of TPS to Software Development, without conflating it with related but separate Agile methods. This is — by far — the best summary of my own thinking I’ve seen to date.