At least not all of them at once. The awareness of quality deficits (these include bugs, lack of understandability, missing documentation, a lack of tests, and so on) seems to follow a sinus-curve like shape.

In those phases with the highest awareness, project managers and their developer teams often decide to dedicate a larger block of time exclusively to cleaning up the system and putting everything else on hold. All too often, the ambitious objective is to remove all quality deficits—in many cases without even specifying what a relevant quality deficit is.

Don’t do this!

Although it depends on which deficits are actually considered relevant, most systems contain thousands of problems of all kinds of severity. And—not surprisingly—the clean-up-everything-now strategy will never work for any realistic project. The reason is that changing source code to remove existing quality deficits always bears the risk of unintentionally introducing new bugs. These may be significantly more severe than the initial problem. Especially when you don’t have a substantial amount of regressions tests, new bugs may be undetected for some time and require expensive fixes afterwards.

Apart from the risk of new bugs, it’s hard to legitimate the improvement of the product’s inner quality. Users want to see bug fixes and new features. Project managers want their money to be spent for some »real« improvement—something that is visible to the user or can be sold to customers. Hence, it is very unrealistic to put all these things on hold for some time. The worst case occurs when both problems appear together. You haven’t delivered bug fixes and new features for some time and the so-called quality improvement introduced a number of severe bugs. In such a case, you can be sure that this was the last time you were given some money to fix quality deficits.

On the one hand, fixing all problems at once is not a viable strategy. On the other hand, doing nothing is not a good strategy either. We recommend a strategy in-between: the fix-as-you-go-strategy. When you fix existing bugs or implement new features, clean up the code that you change. This reduces the risk of introducing new problems, because you need to have a thorough understanding of the code anyway to implement the change. Beyond that, the original fix or feature has to be tested and the changes required to remove quality deficits can be tested in the same run.

The scope of the clean-up should be set appropriately. For example, we can implement this strategy based on files—whenever a file is changed: clean it up. In practice, however, this is often too enthusiastic and cleaning up the whole file is often too much additional work. Choosing methods or functions instead of files is more realistic. You can later switch to files when the number of remaining deficits is low.

For a large part, fixing quality deficits is preventive maintenance—saving future maintenance effort. The fix-as-you-go-strategy tries to increase the saving by assuming that code changed today is more likely to change in the future than code that has not changed for years. Therefore, you make sure that you spent only time for cleaning up code that is actively maintained and likely to change in the future.