Software debt can delay a project and cause quality problems, but is the effort needed to address it worth the cost? In part one of this two-part interview, Chris Sterling, author of Managing Software Debt: Building for Inevitable Change, explains the concepts of software debt. In part two, he gives helpful suggestions on assessing the ROI associated with software debt and advice on how to convince Product Owners of the time needed to address it.
SSQ: If an iteration is spent addressing software debt, is there anything to demo to the Product Owner? What is the best way to convince Product Owners that addressing software debt should be a priority?
Sterling: I do not suggest spending the entire team’s capacity for a whole iteration addressing software debt. A team that we were coaching many years ago struggled to create a valid build of the software in under a week. This was leading to feedback loops for regression testing that was too long and high impacts to feature delivery in upcoming iterations for defects. We asked the team if they could do anything about this problem they were having and they told us it could be solved if only they had enough time. They told us that the Product Owner would never allow them to take the time to fix the issues. We then worked with the team to come up with a list of technical items and prioritize based on how effective they would be in solving the build problems. We then took those technical items to the Product Owner to place in the Product Backlog. The Product Owner asked clarifying questions and started to understand the potential ROI of fixing these issues in terms of accelerated delivery in future iterations. The Product Owner said that he wanted the next iteration to include a special user story with sexy user interface attributes and then fill up the rest of the team’s capacity with the highest priority technical items. But make sure that the special story got completed. The team did this and within a few iterations was delivering four times as much per iteration compared to previous iterations. I have found that “the cost of not addressing” and “increased delivery capabilities in future iterations” are approaches that teams can to use to help Product Owners prioritize technical items appropriately.
SSQ: In many cases, addressing software debt will require an investment in which it isn’t clear whether or not there will be an adequate return. Do you recommend assessing the ROI before making decisions regarding addressing software debt?
Sterling: Yes, I do believe we should at least have an idea of why we should address particular software debt. While conducting due diligence on a company’s software assets for an investment firm we used Sonar and the technical debt plug-in to get an indication of the amount of technical debt. In conjunction with running the static code analysis on all of the software application’s components, we also asked the team about the frequency with which they modified each component. We also backed up their answers with some crude source control analysis. We found out that five of the 11 components hadn’t been modified in six months and the team thought that they didn’t see any reason to modify it in the immediate future. Therefore, we did not believe the technical debt associated with these components was a priority to address in the near future. It is important to not try and tackle all of the software debt at once. I recommend that teams focus on software debt associated with the features they are currently working on rather than just addressing software debt anywhere in an application independently.
SSQ: When assessing ROI for say, regression testing, organizations often compare the cost of automation vs. manual regression testing. But if automated testing is spent on areas that don’t present risk, isn’t the cost higher than the return?
Sterling: Automated testing can be overly costly for the value it provides in some circumstances. In my experience, these circumstances are less common than many teams predict. The problem with some automated testing, such as integration and functional, is that the tools are harder to maintain and the execution cycles are longer than with automated unit testing. Therefore, even if there is a long-term gain because of the confidence they provide the team in making future changes and the increased delivery this enables, it is hard to keep the discipline to reap these benefits. I do not suggest using automated tests for every aspect of an application. There should be some consideration for the cost of maintenance and value the automated test provides along with the automated testing capabilities of the team members.
I am a huge advocate and also trainer of “test first” techniques such as test-driven design (TDD) and acceptance test-driven development (ATDD). We use these practices on our own product, AgileEVM. When planning our test strategy, we use risk and reward to inform our decisions. We have a calculation engine that is a critical foundational element of many features. The calculation engine has nearly 100% test code coverage. In the Web application controller layer, the test code coverage is quite a bit less because that code tends to delegate responsibility to services. There is not as much risk of impacting future delivery in the controller layer of our application. The services have test code coverage that is somewhere in between that of the calculation engine and the controller layer. We add functional tests using Geb and Selenium 2.0 to ensure that critical flows through the application are working across browsers and operating systems. These tend to do just a little bit more than what are traditionally called “smoke tests.” It is important for teams to create a test strategy that is appropriate for their own context.
SSQ: Who is the primary audience for your book, and what will be their biggest takeaway?
Sterling: Managing Software Debt can be helpful to anyone involved in software development. This could be anyone from CTO and CIO level to management to team members. Executive management can set goals for their organizations to help reduce software debt accumulation such as “move towards push-button release.” Management can support teams in setting up monitoring tools that look for early indicators of different types of software debt such as Sonar as a technical debt dashboard or prolific extended use branches in source control that contribute to configuration management debt. And teams can find new ways to increase the feedback on their software development efforts leading to reduced software debt and more valuable, fun software development efforts. By managing our software debt we will build more trust with business by becoming more predictable and able to meet new business needs. This can lead to software development organizations being looked at less as a cost of doing business to an essential investment for business. That is what I am passionate about and want to see happen more and more in our industry.
Chris Sterling is author of the book, 'Managing Software Debt: Building for Inevitable Change', published by Addison-Wesley Professional, Dec.2010, ISBN 0321554132, Copyright 2011 Pearson Education, Inc. Chris is a Partner at Sterling Barton LLC, where he works with clients as a technology, management, and Agile consultant. He has an extensive technology, process, and consulting background allowing him to work with a diverse set of clients and teams. In addition to consulting, he is a Certified Scrum Trainer and Innovation Games Facilitator. He also teaches the Advanced Topics in Agile Software Development course at the University of Washington for the Agile Developer Certificate extension program. For more information on the book, and a sample chapter, Chp#4, "Executable Design," please visit the publisher site "Sample Content" tab below the book image.