the value delivered. Return on investment (ROI) is affected negatively, and management attempts to minimize this by not adding as many resources as the team asks for, if any.
Even if business owners covered the costs of extra resources, it would only reduce the rate of debt accrual and not the overall software debt in the system. Feature development by the team produced artifacts, code, and tests that complicate software debt removal. The cost of fixing the software debt increases exponentially as the system ages and the code-base grows.
Software debt in the system continues to accrue over time, as shown in figure 1.3. At this point, new feature implementation is affected significantly. Business owners may start to reduce feature development and put the system into "maintenance" mode. These systems usually stay in use until business users complain that the system no longer meets their needs.
Managing Software Debt
There are no magic potions for managing software debt. Software can accrue debt through unforeseen circumstances and shortsighted planning. There are some basic principles that help minimize software debt over the lifespan of the product:
- Maintain one list of work
- Emphasize quality
- Evolve tools and infrastructure continually
- Always improve system design
- Share knowledge across the organization
- And most importantly, hire the right people to work on your software!
Maintain One List of Work
One certain way to increase software debt is to have multiple lists of work. Clear direction is difficult to maintain with separate lists of defects, desired features, and technical infrastructure enhancements. Which list should a team member choose from? If the bug tracker includes high priority bugs, it seems like an obvious choice. However, influential stakeholders want new features so they can show progress to their management and customers. Also, if organizations don't enhance their technical infrastructure, future software delivery will be affected.
Deployed software considered valuable to its users is a business asset, and modifications to a business asset should be driven from business needs. Bugs, features, and infrastructure desires for software should be prioritized together on one list. Focus on one prioritized list of work will minimize confusion on direction of product and context switching of team members.
Emphasize Quality Towards Executable Design
Going beyond the design/code/test software development flow to building integrity in as we go is the first step to emphasizing quality. Executable Design is an approach involving existing well-known practices, effective principles, and a mindset shift that is heavily influenced by Agile values and principles. The principles of Executable Design are:
- The way we design can always be improved
There is no general way to conduct software design and attempts to do so will reduce value delivered by teams and increase costs to manage.
- You'll get it "right" the 3rd time
Customers change their mind, technology gets better understood, and teams learn more about the software's domain as they construct the software. Find ways to incorporate this learning to properly incorporate effective change.
- We will not get it "right" the 1st time
Unfortunately, as an industry we have not been successful in determining what customers want before they interact with the software. Short iterations allow teams to give customers what they think they want quickly and get valuable feedback on changes the customer identifies once they touch and feel the software.
- Design and construct for change rather than longevity
Defining the software's architecture and design is not to create software that lives a long time. It is to make the software's structure changeable to meet