Productive Paralysis
March 8, 2010
Having an unproductive, unhappy organization likely ranks as any general manager’s worst fear. Yet, this terrible circumstance seems to strike at the best of us, even at those with the best of intentions.
What I find especially interesting is the form of paralysis that comes about from overproduction. Eliyah Goldratt covers examples from manufacturing plants in The Goal, but it also happens in software/development shops in very interesting ways.
It goes something like this:
- A team builds a lot of stuff very quickly, so the architecture becomes increasingly fragile and tricky to negotiate.
- The pressure to continuously build (and release) new stuff continues and even grows louder and more oppressive.
- If we compare features and customer satisfaction as a function of engineering effort, the product has seemingly hit an asymptote of diminishing returns.
- As a result of both the difficulty of engineering on the platform and the pressure to ship, features increasingly generate larger and more difficult bugs, requiring constant fire-fighting. Yet, the team can do nothing about this because they are short on the staff, the time, and the energy to create a better architecture in parallel to swap out with the unmaintainable status quo.
- Fire-fighting interferes with the team’s ability to engineer new features, requiring more and more effort for less and less return.
The team is eventually rendered almost wholly unproductive yet extremely hard working, an odd and contradictory dilemma.
Software releases–especially web releases–tend to be motivated by big promises and the momentum of “rolling thunder” iterations and updates. The solution to the situation above isn’t especially difficult to see; in any compromised release (and all releases are compromised to some extent), time, quality, and/or features must suffer. One answer to making something more maintainable and workable is to expend more time to build it right. Time pressures, however, often conspire against good but time-consuming design in favor of dirty but fast hacks and tricks that will have to be paid for in maintenance later.
The answer is widely known but counterintuitive. To speed up, sometimes, it’s necessary first to “slow down.”
