Unsustainable Software Development and its Causes
- Technical Debt and the Flywheel
- The Perils of Jumping in Place
- The Causes of Unsustainable Development
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Unsustainable development, as depicted in Figure 2-1, is an all-too common situation today in the software industry. Most software teams place too much of a short-term emphasis on feature development and fixing defects and do not pay enough attention to the health of the underlying software. The result is software with a high cost of change, that is increasingly unmaintainable, and where every change has the risk of destabilizing the product.
)
Figure 2-1 Unsustainable development is characterized by a constantly increasing cost of change to the software. The usual evidence of a high cost of change is a constantly increasing number of defects. Each change adds complexity and uncovers or causes defects that require more changes, and this complexity leads to a declining ability to respond to customer requests and changes to the ecosystem.
In unsustainable development, teams tend to spend an ever-increasing amount of time fixing defects and stabilizing the software. Features still get developed, but less time is available for feature development due to the amount of time required to stabilize the software, which increases with each new release. This results in teams tending to become change-adverse while they are stabilizing the product because each change increases the risk that something will break. Teams tend to desire freezing of requirements as early as possible so they can get some work completed. This reduces their ability to respond to customer requests and changes to underlying hardware or software because they are spending too much time on stabilization, which is wasted effort, and not enough on new work.
The symptoms of a short-term outlook are only evident once a threshold has been crossed. This is the point where the development team starts to spend so much time trying to keep up with the defect backlog that they are noticeably unable to spend enough time to develop new features. It may take only a few months or many years to reach this point. Many development teams may not even be aware how bad things are: Release cycles might become death marches, customers, management, and sales force complaints might get louder, and developers themselves will start blaming the problems on management ("if only they had listened to me...") and other developers ("they produce too much buggy code..."). It may take a while, but morale will eventually suffer then plummet; in extreme cases, people will lose their jobs through being fired, layoffs, or outsourcing, and customers will lose patience with the product and company.
Luckily, the extreme is seldom reached. Unluckily, most project teams live in a gray area that is not sustainable development but is uncomfortably close to unsustainability. These projects have not reached the threshold where the problem is obvious; developers feel like they are barely keeping up or are making slow progress but with too much stress. This is the software development death spiral, where the only variable between unsustainable projects is the rapidity of the descent toward obvious unsustainability.
Technical Debt and the Flywheel
The underlying cause of the inability to develop new features due to a defect burden is what is best called technical debt. Technical debt is caused by an accumulation of poor decisions over time—decisions that often seem right at the time but are usually made in the interests of a short-term quick fix to the software. Very rarely is it possible to identify a single decision that stands out as one where the problems might have started.
Jim Collins describes a relevant flywheel metaphor [Collins 2001]. Collins uses the flywheel metaphor to describe how decisions affect momentum in an organization. Think of a massive flywheel that is so large all you can do at first is give it tiny nudges that move it an inch at a time. Your organization’s sustainable development emphasis is like continually providing tiny nudges. Each new nudge adds momentum to the flywheel so that it continues to pick up speed. However, every decision to develop a new feature or fix a bug by introducing an ugly hack or ignoring the underlying architecture acts as a brake on the flywheel. The software development death spiral results because these brakes, or nudges in the wrong direction, will eventually stop or even get the flywheel spinning backwards. How fast the flywheel is spinning and its direction is something your organization should be aware of.