Stop Passing the Buck on Technical Debt

by

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!"

Filed in:
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Jonathan Bloom
Jonathan Bloom Technology Writer & Consultant
Jonathan Bloom has been a technology writer and consultant for over 20 years. During his career, Jon has written thousands of journal and magazine articles, blogs and other materials addressing various topics within the IT sector, including software development, enterprise software, mobile, database, security, BI, SaaS/cloud, Health Care IT and Sustainable Technology.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|