Software decays over time due to changes in the code and the technology in which it operated. All of us have been in the situation where fixing a single issue can produce several other defects. I also have been through situations where executing a piece of code causes an unforeseen—and sometime disastrous—outcome. These are examples of software rot.
There can be umpteen reasons for software rot. Over time as an application becomes more complex, testing becomes increasingly more complex as well. This allows sneaky defects to bite at the most inopportune time. Avoiding design changes, failing to follow the process, and applying hacks to get over the current pressing problem are all valid reasons for software rot.
However, where does this all start? Think software entropy. Using the “fixing broken windows” metaphor, the authors of The Pragmatic Programmer suggest that lingering bad designs, wrong decisions, or poor code can lead to increasing rot.
If the first issue lingers around for a substantial amount of time, it can lead to a slippery slope, and there might be no turning around. The end result is a brittle application where a small change could be prohibitively costly.
On one hand, you could argue that adoption of agile methodology might be full of traps. In a whitepaper Mark Collin-Scope contends that software rot might be encountered much sooner in agile than in traditional waterfall process unless right measures are taken. After all, it is tempting to apply hacks to support a requirement in the name of agility and adaptability. How can we forget that the Agile Manifesto values “Responding to change over following a plan?”
However, it is also intuitive to think that the application of agile methodology provides the best tools to decelerate software rot.
One of the major contributing factors in code degradation is lack of flexibility and will to change design. Agile embraces continuous design changes and code refactoring to meet challenges from emerging requirements. This inherently promotes practices that prevent software decay.
Additionally, designing for testability is of utmost importance. If every line of code that gets added or updated is tested thoroughly, there will be no unexpected behavior displayed by the application. This calls for developers and testers to have a well-defined testing strategy.
Lastly, adhering to standards makes it easier to maintain and extend code, to refactor it, and to reconcile integration conflicts. Software is rarely maintained by its original authors. Applying standards in a consistent manner helps to maintain code quality during active development and after the application has transitioned to maintenance mode.