This chapter is from the book
This chapter is from the book
This chapter is from the book
Bad Assumptions
The manufacturing mindset assumes that
-
The problem is predictable
-
The problem is controllable
-
The focus should be on optimization
When those things are true, it makes sense for software development managers and their teams (as the manufacturing mindset tells them) to understand the overall problem, to design the best solution, and to implement the design efficiently. Then they should repeat the process to make it maximally efficient. In this way of thinking, optimization is king, and we've carried it straight over to software development. Software development managers have been taught and encouraged to treat software development like an efficiency optimization problem. They got suckered.
I don't hear too many people claiming to use a waterfall process anymore, probably because they fear being laughed at, but consider how people in most software development organizations do things. They still make software by saying they'll understand the problem by creating (they hope) an exhaustive functional specification, by designing the best possible system to meet the spec, by implementing the design through maximally efficient coding, and by repeating and refining the process. This is the manufacturing mindset applied to software, and you can see the same three assumptions:
-
That we can make useful, detailed, accurate long-term predictions about software development.
-
That we can control events and people to make our predictions come true.
-
That our attempts to control will produce the results we want.
The first assumption is critical. If it's not true, the others are moot (more on them in the next chapter). The only way the four-step process of the manufacturing mindset makes any sense is if we can predict the future very well. When you look closely at the typical software development plan, you can see that assumption in there.