When You Should Start Paying Off Your Technical Debt

by

Much of what comes with being an entrepreneurial leader is knowing when to accept certain tradeoffs. When you have a whole organization under your control it is impossible to constantly uphold a perfect balance; the result is often times compromises and temporary fixes. These compromises and short-term solutions are what is called technical debt. While technical debt is not an inherently negative concept, if left unchecked it become an additional risk in any organization.

At any software company technical debt invariably becomes an important topic of conversation. The focus of these conversations should be on when to let technical debt persist and when to start paying it off. In order to do this though, you need to understand what technical debt entails.

Technical debt is the result of fulfilling an immediate need (with a compromise on the quality of your code) that comes with some serious long-term consequences. And like credit card debt, technical debt has high interest rates that compound over time - making it more difficult to pay off the longer you let it remain in your code.

The CEO of BodeTree discusses how at the inception of any company, in order to find the adequate market fit for their product there is a inherent process of experimentation, adjustment, and iterations of code that lends itself to the creation of technical debt. But when should this technical debt be accepted, and when should you start to plan on paying it back?

If you are looking at a company in its early stages of development then there is likely to be quit a bit of accrued technical debt - this is just part of doing business. So you should be willing to accept technical debt in the following three situations.

  1. When you are dealing with your first big customer: quick iterative development and adjustments lend itself well to this scenario when you are looking to refine the product quickly to customer feedback. Therefore, technical debt becomes the means to an end.
  2. When you are building a minimum viable product due to a lack in secure funding: development work is costly so building quick and dirty may be your only option in order to get the product out on the market.
  3. When you are testing new features in an established product: sometimes a new feature may not even be the right fit for your product or market, so it makes sense to cut corners in development in order to see if the feature is even worth your while.

These are the times when you should let technical debt be; but when should technical debt be seen as an untenable part of your code base?

The time to pay it back would be when it begins to show itself by affecting the performance of your product and the efficiency of the team.

What are the signs of reaching such a point?

You will know that you've reached this point when making changes to your product becomes an arduous task to the amount of features that are interconnected. Your code will become brittle and any change could have some serious ramifications in other areas of your code that could result in breakages and software outages.

For BodeTree the signal was clear when a sudden influx of customers revealed what features were not being used and which features weren't working. The BodeTree team was able to identify what could be cut out and therefore focus on the quality and performance of the code in their system - in the areas that mattered most. A strategy like this saves capital because it allows you to surgically correct the areas where technical debt is the most costly and prioritize your development work accordingly.

The key, as mentioned at the start of this post, is knowing what the right balance is of acceptable and not acceptable technical debt is in your organization.

To read the full post visit here.

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

|