Failed Metaphors
No software factory, no vehicle construction process
Another presentation about Agile Methods and again the one with the slides compares with Waterfall. In the end Agile Methods succeed by turning a stroller into a car. Waterfall only came up with something that looks as if a 3-year-old had put together all kinds of parts of different sizes in odd numbers which doesn't drive at all.
I'm not a car engineer but I know two of hundred other concepts why todays cars are easy to handle: a differential gear in the rear axle in German Hinterachsdifferenzial I like these long words. The other is Querachslenker (transverse axle link) which is the set of hinges, springs, damper and metal bars so that the front axle is suspended, steerable and sometimes driven by the motor. Now compare this to the stroller from the presentation or any other minimum viable product you created from scrap parts in one of those team events. It often was something with a pallette, a solid axle and two wheels turning freely. This is far away from the two aforementioned concepts.
If I were the first car engineer I would presumably not come up with a differential gear. Instead assuming I am an experienced engineer with the task to invented a new way of driving experience I'd stick with transverse axle links I know today. Solving problems while completing user stories has nothing to do with evolving a stroller into a car.
The second inadequate metaphor sees software development similar to combine building blocks, components or patterns. It is only necessary to find those patterns or components. Then they are put in a toolbox. Finally they are taken from that toolbox to combine them. This is like building with prefabricated slabs in the 1960s. All buildings look exactly the same. Modern concrete factories adjust their molds and deliver a flexible palette of slabs. Walls and floors are similar in one building. But no building looks like the other. If they were architects would be unemployed.
There were so many tools and methods in the last 40 years. None of them was the one solution for all problems. There is the niche of model checking with a general theory. It fails with mainly input driven software. It would not be necessary to have full stack developers or the devops role. Why is it necessary to migrate software built from standard components? Or isn't it more likely that a really un-maintainable big ball of mud is to be replaced, multiple times?
As a third metaphor I chose the software factory as it has been hunting me now for more than 20 years. In addition to the standard components already mentioned above there is a conveyor belt in a factory building. A large number of identical objects is put together. The product is a finished design. Todays factories let us return to car industry depend on a long chain of suppliers. Suppliers themselve provide complete parts as their products. Switching such a factory to a new model or different type of vehicle does not happen within a monthly rhythm.
You may come up with the argument that elements of a programming language are like screws and metal plates. Or using a library could be a supplier dependency expressed as such in a pom.xml of Maven or Autotools scripts. This is still a failed metaphor. Workers at a conveyor belt don't think about how and which of the screws, plates, dampers and springs solve an invdividual transportation problem. Maybe a compiler can be seen as a conveyor belt turning a high level language into machine instructions.
There was also never a project with hundreds of software developers where one added the prefabricated for loop, another attached error handling for database queries and so on. Until a last worker followed a set of simple tests like head lights, horn, doors, engine and driving a few hundred meters to deliver a final product. True developers test in production.
Update 2022-06-27T21:00:00
Fixed publication date.