Technical Debt: Not Just a Technical Problem

by

Technical debt has come around as being the keyword of the moment in the industry. It has probably come up in developer team conversations concerning legacy code, refactoring efforts, new feature development, or a recent system failure. Tech debt can often be used a warning against short deadlines and poor communication between business and technical stakeholders. Ultimately, technical debt is a concept that is both time and wisdom sensitive.

However, it is always important to understand that technical debt is not an entirely bad thing, but it also isn't an excuse to write bad code. Technical debt is meant to enable developers to write code born of their current understanding of a particular problem. This doesn't mean writing a sloppy solution, but it means that perhaps the best solution at the moment won't be the best solution in the long run. In order for technical debt to be a positive for an organization, however, the value of putting out your coding solution now needs to outweigh the cost of fixing it later down the road.

The description above is analogous to interest on a financial loan, but this sort of analogy is usually as far as the technical debt metaphor goes in terms of interest. Often times the human side of technical debt that can end up costing more than just accrued interest.

Technical debt often becomes very apparent towards the end of project deadline, when there is little time left and features can't be dropped. Usually, the first thing to be abandoned in such a scenario is code quality: proper testing isn't enacted, code starts to become illegible, and the software becomes less maintainable. This isn't a huge deal, because releasing code that is a bit buggy is not nearly as detrimental as falling behind to competitors because features are never released.

The reason why this becomes problematic is because it's never just one project that throws out code quality in favour of expediency. There never seems to be time to fix the issues of the previous release and so the pile of technical debt only gets larger and larger. And if you then decide to go and fix bugs or update certain features in an environment like this, what should have been a short task can take days.

It may seem counterintuitive to innovation to halt on releasing features in order to pay back technical debt, but in the long run if technical debt keeps piling up in your code base releasing new features will be next to impossible.

We mentioned at the start of this post that often times technical debt becomes problematic due to poor coordination between business and technical stakeholders, so what can both sides do to help the problem?

As a manager it is important that your trust your developers. When they say that a deadline can’t be reached without cutting out quality, they are right. This also means that when developers ask for time to pay back technical debt is a necessity and not just a commodity, because it will help releases go smoother in the future.

While it is important that managers are understanding of their developers, this can’t occur if developers aren’t communicating with them. Assuming that your manager won’t know what you’re working on will only ensure that they never will. In order to build good lines of communication you need to be realistic with your teams abilities and create a culture of building good code so that everyone is on the same page at all times.

Here's a great webinar on how to deal with technical debt with a more specific approach:

Filed in: Technical Debt
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
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

|