Software Engineering management is way more art than we want to admit
Once upon a time, the management of factory workers was a reasonably prescriptive endeavour. The output was uniform (nuts and bolts), easily quantifiable, the workers were easily replaceable, and the amount of knowledge required by workers was small. As a result, you can have a playbook that governs the majority of the situations.
If you think about it, the waterfall model was heavily based on the manufacturing process. So let’s gather all requirements, design a new product, let’s build it, let’s have quality control at the end, and let’s ship it to the w̶a̶r̶e̶h̶o̶u̶s̶e̶ (oh sorry, I meant to the production).
And it goes beyond a production conveyor belt. The hiring practices, management style, measuring performance, and so on were also heavily based on manufacturing and construction practices.
It is nice to see that industry gradually matured for the last twenty years, and people started to look around, scratch heads, and say that software engineering is very different from manufacturing. It has a huge amount of software discovery (finding and figuring out known and unknown unknowns). This discovery is, by definition, unpredictable. Old models (like waterfalls) lead to an amazingly high rate of failed projects. Old ways of management (with a whip) don’t work well on hard to replace knowledge workers. The old methods of measuring performance (KPIs, anybody?) go off the rails really fast.
.png)
