The IT Manager's Dilemma with Software Debt
“The team continues to complain about working with that legacy codebase because it has so much software debt. That software debt slows them down in feature delivery and they are wondering if we can push for priority to be put into paying it back some?” asked the ScrumMaster. The IT Development Manager looked distraught about the request. She knew that paying back some of the software debt would be a valuable effort but what would the business say about the priorities? “Tell the team that we’ll start paying back some of the software debt starting in the next release. We must get the current release out the door and a change in priorities won’t allow us to get there.” the IT Development Manager said.
Considering the circumstances I cannot tell an IT manager that this approach is not the right way to go. In many cases the IT manager is not in a position to push for technical priorities even when they will provide value to the business. As teams continue to develop on a system without managing the software debt effectively feature delivery throughput decreases. The following picture shows a team’s feature delivery throughput versus time spent stabilizing each release over time:
There are many reasons for this software debt accrual:
- Pressure of the deadline
- Inexperienced team members
- Bad design
IT management has looked for ways to minimize the effects of software debt. We introduce processes that in theory will reduce software debt but in reality seem not to lessen the effects at all. Tools are introduced that will ease the software development process but we still see similar or potentially new mistakes made by team members. Individual team members are asked to specialize in particular software development disciplines such as Database Administrator (DBA), Quality Assurance (QA), or Business Analysis (BA). Although we do each of these specialized roles more efficiently it seems that the product delivered still is accruing software debt. So what do we do?
It is my experience that teams that adopt agile test and engineering practices within an organization that supports collaboration between business units and development teams are more successful in the containment of software debt. These teams tend to minimize software debt and will at the very least deliver with consistent throughput release after release. In some cases I have seen teams accelerate the velocity of their feature delivery throughput over time. The following figure represents the problem IT managers have in deciding to manage software debt effectively on existing legacy software:
A team will have to slow their current feature delivery significantly in order to get consistent throughput over time. I would suggest that managing the software debt effectively would be the best decision for a business relying on this software. Software is a valuable asset for businesses that can:
- Reduce costs for business processes by automating significant portions
- Provide information to business quickly so they can make better strategic decisions
- Attain market share providing shrink-wrapped software to meet the market’s needs
- Reduce system decay on existing software assets so they can be used into the future
- and much, much more…
Still, given all of these reasons it is difficult to take on software debt in the wild. We must understand that a typical IT manager has many influences on their decision making, as well:
- Business pressures for a set of features on a certain date for a set cost (The Iron Triangle)
- Expectations of feature delivery based on past software releases
- Unreasonable deadlines due to business issues such as lapsing support contracts and executive management promises
- Perception of their organization and how that reflects on their capabilities
- A compensation plan that does not reward managing software assets for future capability
Given all of these circumstances I believe that IT managers are making the best decisions possible. How can we help IT management support our organizational software assets effectively and minimize the effects of software debt? What approaches will allow the software delivery teams to manage software debt while delivering essential features? How can business get more involved and increase understanding of this dilemma that will affect the organization’s capabilities over time? I am interested to hear from anybody who reads this. What are your suggestions?