Software development is not an assembly line

Analogies are useful to a point. They allow people to relate new ideas back to something they are familiar with, giving them a safe framework from which to explore new territory. However they can also be immensely damaging and misleading. I was recently reminded of one  particularly well worn example of the latter type that needs to be laid to rest once and for all:

Building software is not the same as building a car. Developing a software product is definitely not a simple assembly line process.

When building a car on an assembly line, you make the individual components - wheels, engine, chassis, seats etc - and then construct the finished item from these. Each component has already been designed in its own right, and they have all been proven to fit together many times previously. There is absolutely no creativity involved in the construction process. There are limited opportunities for different combinations of components (and those that are possible are well tested).

Software development is a fundamentally different problem. You don't have a set of predefined components. But you do have close to an infinite number of ways to build the final product. Individual components making up the final product need to be built, and so have not been proven to work together. The whole construction process requires a huge degree of creativity to produce a final, working deliverable. The nearest you can get to a car manufacturing analogy is to think of building software as attempting to build a car from raw lumps of metal, with no existing, pre-proven designs for the components. Trying to emulate an assembly line by believing that you can build component after component and expect them to immediately bolt together without problems will inevitably lead to tears before bedtime. Yet many teams still fall into this trap.

If it can be related at all to this analogy, software development has more similarities to car research and development than manufacture.

Consider this. A new car design is first prototyped as a collection of conceptual drawings that are iterated towards a final design. Then these are fleshed out to various models and mock-ups which would never make it to the forecourt, but which are used to invite more feedback. Then working prototypes are produced, and again, more feedback obtained, and designs iterated (or the design is shelved or binned). Finally, after many, many iterations, there is a new model of car available to purchase. Sounds familiar? Iterative software development creates a simple demonstrator of the system, then keeps on adding to it, refining both the functionality and the design until it is good enough to release to users.

This is where software development fits. It has more in common with pre-manufacture prototyping than assembly lines. But this doesn't stop us from stealing relevant, useful ideas from the assembly line. Kanban, anyone?