Software projects, eventually, go through one or more “Cycles of Agony”.
At the start of a software project, opportunities look promising, productivity and motivation is high. It takes experience and sweat to come up with a somewhat stable initial structure that is instructive, scales with the problem space, is sufficiently modular (i.e. keeps complexity manageable).
Regardless how well you manage all necessary compromises (e.g. productivity vs. process), how well you were able to foresee required tools and technologies, how well the business case was understood: Projects (if not abandoned) eventually run into a state of unproductivity that shows one or more of the following symptoms:
- Developers are unsure on how things are supposed to be done,
- The architecture tends to show unneeded abstractions of previous abstractions,
- Conceptual integrity breaks down,
- a general fear of touching things that “worked before” (no daring)
It’s unavoidable. Inherently, the business scenario at hand is only partially understood and will most likely change over time, inherently new use-cases, new technologies to integrate with, new customer requirements will show up (why spend money on developing a new software otherwise at all?). Hence the probability to make only the right far-reaching decisions is essentially zero.
The Agony Cycle looks somewhat like this:
If the solution at hand is a “cash cow” (rather than a star), it may well make sense to not dare big change and consciously move on into indefinite maintenance (and for developers to leave). Otherwise though, tough decisions are required to get you back on track. Previous decisions have to be reverted, possibly requiring non-trivial refactorings that do not result in immediate benefits. Although you (hopefully) have a product already, you need to pay a price that doesn’t linearly add obvious value (a concept that looked much more acceptable in the beginning). Whereas in the beginning of the cycle craftmanship was essential, now the willingness for change is key to further success.
In larger organizations, the risk of change may be considered too high and the need of change is politically undesired. That’s one reason why we see seemingly inexplicable failure to innovate on existing products by big players in the market.