Stop Passing the Buck on Technical Debt

After listening for many years about the European debt crisis, the downgrading of U.S. debt and every other tale of woe about debt, I believe my patience is owed an enormous debt...and seeing as today is my birthday I would like it paid off immediately!

I don't think I'm asking too much.

For decades, governments have spent more than they’ve taken in and then kicked the issue down to the next generation of leaders.  Didn’t anyone realize there would be a day of reckoning?  And that this “reckoning” would come in the form of populations revolting against higher taxes, debt holders refusing to buy more bonds and other things equally unattractive?

Many pundits try to compare government debt to a family’s debt, reasoning that just as families cannot continuously spend beyond their means, governments should not. Other pundits call this comparison naive, since government finances are vastly more complex than a family’s.

Naive?

Really?

Ask the Greek prime minister just how naive this is as he tries to navigate an impossible course between leaders of members of the European Union reluctant to lend Greece more money and Greek protesters enraged by the prospect of fewer jobs and higher taxes.

The Price You Pay

And while the financial debt crisis grows globally, so does the technical debt crisis. Brandon Hoyer recently launched into a rant about technical debt. Having just spent 6+ hours refactoring someone else’s code who was too lazy to do it himself, he asks why developers can’t refactor chunks of code before cutting and pasting them into new projects, .

Looking at technical debt from the view of a startup, entrepreneur and self-proclaimed cyber addict Mohammad Forouzani takes a somewhat less contentious view. He says:

Being in a startup often means you take the path of least resistance to get the job done – you have to, it’s one of the advantages you have to being small, you are agile and can get things done fast, something corporates can’t do because of all of their business processes and red tape. But cutting corners can lead to problems – it usually encourages developers to build things the quick and dirty way, just to meet a deadline or beat the competition. This technical debt, which accrues interest in the form of extra effort required for future development work, can be a major burden on a startup technical teams – to the point of losing staff or inviting hackers to compromise your systems.

He goes on to note that he has seen investors pump millions into a business with "a codebase that is so poor, it could be compromised within minutes, and requires a complete overhaul to allow for further scaling."

Forouzani acknowledges that there’s no way to have a perfect codebase all the time, that technical debt is endemic in any sizable project, and that it is critical to make sure it’s managed and contained at a reasonable level. It’s OK to have some technical debt, as long as developers realize there’s a point where the interest paid becomes unmanageable and extensive refactoring becomes necessary just to continue the project. There is a balance between completing the project on time and ensuring technical debt doesn’t get out of hand.

Take 'Em as They Come

Lisa Crispin and Nanda Lankalapalli, in a stickyminds.com post, float the idea of “technical debt sprints,” devoting an entire iteration to refactoring and other activities  to make code more maintainable and understandable, create new ways of working better, upgrade test and code framework and tool versions, and improving automated tests. While developers may counter that the product owner will never allow an entire iteration to be devoted to addressing technical debt, the authors argue that a technical debt sprint takes the same time as spreading out refactoring activities over the entire project, yet yields the extra benefit of helping developers gain a better understanding of the technical debt situation.

If developers position the sprint as an opportunity to maintain or increase the pace of completing the project, owners are more likely to understand the concept. Core activities teams should think about incorporating as part of a technical debt sprint include:

• Code cleanup – The sprint is an opportunity to remove unused code or an unused database column, or refactor code that bothers the development team. Cleanup is also an opportunity for reorganizing or refactoring automated tests, removing unused tests and making any test changes associated with code changes.
• Software upgrades – Upgrading third-party software, including test tools, can be a valuable sprint function, enabling developers to start using the newest and most powerful software features.  Delaying software upgrades can result in being stuck with a version that’s no longer supported.
• Build features that reduce supporting activities – Identify small features that will reduce the needs for production support, which will speed project velocity.

The World Needs You Harry Truman

Whether developers follow the path of a “technical debt sprint” or manage technical debt at an ongoing pace, an important partner in managing debt are solutions that apply advanced diagnostics to identify and quantify the structural flaws that add to technical debt, as well as supply developers the tools to proactively manage and reduce it. These solutions help ensure that developers meet or beat project deadlines by maximizing velocity, improve developer productivity, and contribute to an agile and lean software development environment.

And with the new year now upon us and another new year of my life about to commence, it would be refreshing if, rather than contribute to more debt - be it financial or technical - someone would invoke the wisdom of Harry S. Truman and decide that "the buck stops here!"