Chapter 2. Unsustainable Software Development and its Causes

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.

Unsustainable Development and the Boiled Frog

If you are working on a project on the unsustainable development path, you may not be aware of it. Think of a frog and a pot of water. If you drop a frog into a pot of boiling water, it will immediately jump out. But if you put a frog into a pot of cold water and then slowly heat it up, the frog will stay put until it is boiled.

Have you ever been away from a project for an extended period or joined a new company and felt like you jumped into a pot of boiling water? It's amazing what we will tolerate if we've been in a situation long enough.

The difference between you and a frog is that you aren't a victim of circumstance. You have a significant ability to influence the temperature of the water through your actions and by collaborating with others. You can't directly control the temperature, but you can keep it within a comfort zone. But you have to be able to make an honest assessment of your situation and be willing to make changes . . .