Managing Software Debt
Most software developers are all too familiar with a scenario in which their Product Owner or Project Manager explains that all of the features to be built in a product are equally important. That is, the manager wants them all and he wants them now. Of course, such demands are rarely rooted in reality and typically reflect the pressure placed on a manager from stakeholders and customers, not the true expression of priorities for what is to be built. Not only does such a request place an unreasonable demand on development teams, but it also creates a long-term risk known as technical debt. That is, when software is developed hastily—without regard for maintaining clean, workable code—the team ends up delivering a product with code so buggy and erratic that maintaining or expanding it becomes a frustrating job that can only be performed by a handful of developers.
In a recent article on Agile Journal, Chris Sterling discusses a form of technical debt called software debt, which he defines by the following criteria:
· “Technical Debt: those things that you choose not to do now and will impede future development if left undone;
· “Quality Debt: diminishing ability to verify functional and technical quality of entire system;
· “Configuration Management Debt: integration and release management become more risky, complex, and error-prone;
· “Design Debt: cost of adding average sized features is increasing to more than writing from scratch; and
· “Platform Experience Debt: availability and cost of people to work on system features are becoming limited.”
As you can see, software debt entails many of the same risks as technical debt and results in the same obstructed path toward sustainably editable code. So what’s the answer? How can organizations take steps to limit the frequency and degree to which software debt impacts development projects? In his article, Sterling sketches out some guidelines that will help developers and managers skirt design death: “Emphasize quality,” “Evolve tools and infrastructure continually,” “Share knowledge across the organization,” and more. However, these recommendations, in my mind, seem too soft and fuzzily outlined to keep teams from caving to management pressure or cutting corners.
For my money, no other agile framework is as capable of minimizing technical and software debt as Scrum. Its iterative and incremental nature provides regular opportunities to halt work and evaluate the progress made for quality and market relevance. Similarly, the framework and its regular work cycles can be used to prevent this kind of debt from accruing by simply creating repeated Product Backlog Items that address issues related to code quality. There’s a big difference between functional code and code that has been scoured for bugs and prepared for a seamless hand-off to the next developer who works on it.