As we all know, Sundays are for football, and this past Sunday brought some choice matchups. Although I am a devout fan of the New England Patriots, one of my favorite games paired the undefeated Green Bay Packers, led by quarterback Aaron Rodgers, and Eli Manning's New York Giants. Tied with less than two minutes to go in regulation, Rodgers did his best Tom Brady imitation, leading his team on a spectacularly engineered drive that preserved their as-yet unblemished record.
After the game, I wondered if Giants Head Coach Tom Coughlin repeated his prior week's answer to reporter’s question, where he stated that his staff had prepared the team, but the team hadn’t delivered. It also made me think more about technical debt and the question I posed (and hopefully answered) last month: “Is there a technical tipping point?”
Then, I read Gartner analyst David Norton’s post on technical debt, where he quotes his colleague Andy Kyte as predicting technical debt will top $1 trillion within the next five years. Norton states, “that’s a trillion dollars of development that needs to be done to remove bad code, poor architecture, and ill-thought-out technical strategy or simply time catching up with good design.”
As I dug into this more, I came across an excellent presentation from Thomas Sundberg of Sigma Software, which he presented at the Agile Sweden 2009 conference. While it’s two years old, it really got “into the weeds” about the causes and results of as well as potential solutions for technical debt. I thought it would be worthwhile to share a few of his key points here.
With increasing turnover of IT teams and outsourcing software development, it’s critical that developers are educated in the domain and that there’s a process in place to retain information. In many organizations, each time there’s a staffing change, knowledge is lost. Sundberg asks, “if you don’t understand the problem you need to solve, how can you solve it?”
He adds that given an environment of continuously changing talent, teams should always verify their assumptions and these should be stated as clearly as possible as part of the planning and ongoing communications process. “Incorrect assumptions are the mother of all f**k ups,” he notes.
Another contributor to additional technical debt is premature optimization. Premature optimization can cause developers to optimize the wrong feature, resulting in code that isn’t used, an incorrect solution or a solution with unnecessary complexity – all a waste of time and resources.
Sundberg offered a host of ideas to reduce technical debt. I realize several of these are elementary, but in the bustle of meeting everyday objectives, several of these practices can easily fall by the wayside.
Team communication is critical, especially when development is spread out between in-house and outsourced talent. Managers must identify team rules and stick with them, discuss the pros and cons to each solution and then choose one approach and stick to it as long as it makes sense. This may sound easy, but when developers create their own rules and generate different solutions to similar problems, they waste time and resources.
Sundberg notes that when teams fall into technical debt, they should plan immediately for how that debt will be repaid, but the debt doesn’t have to be repaid immediately. He pushes for teams to have a plan that pays it down at a sustainable pace, but is adamant about identifying the debt and creating a roadmap for paying it off.
Managers should consider paired programming to avoid the knowledge drain that occurs when staffing changes. This approach can result in better code development, including knowledge and experience on a given task from two developers versus one, while also ensuring that institutional knowledge stays within the organization.
Managers should think about test-driven development (TDD), which encourages developers to solve a problem twice, and then work with the optimal of the two solutions. Sundberg notes this can result in at least the doubling of code quality.
Sundberg continues that living with small errors will eventually lead developers to accept larger ones, building in technical debt in the process. The first time a developer says, “I’ll fix that later,” he/she is creating new technical debt.
Ensuring there’s discipline in the refactoring process will help wring out technical debt as well. Sundberg encourages developers to run all tests, seek out the simplest solutions to fix problems, then run all tests again and only when all tests pass should developers run checkin. Sticking with this approach will decrease technical debt.
Finally, Sundberg concludes by commenting that you pay down technical debt the same way you eat an elephant – one bite at a time. Such simple ideas could spell the winning formula for reaching state of reduced reduced technical debt and optimal structural application quality - the "Super Bowl of Software."