Showing results for 
Search instead for 
Did you mean: 
Create Post

Don't Let Technical Debt Be Your Company's Subprime Loan: Mapping Your Way to Better Software

Level 10

I was in the pub recently for the local quiz and afterwards, I got talking to someone I hadn’t seen for a while. After a few minutes, we started discussing a certain app he loves on his new phone, but he wished the creators would fix a problem with the way it displayed information, so it looks like it does when he logs in on a web browser.

“It’s all got to do with technical debt,” I blurted out.

“What?” he replied.

“When they programmed the app, the programmers took an easier method rather than figure out how to display the details the same way as your browser to be able to ship it quicker to you, the consumer, and have yet to repay the debt. It’s like a credit card.”

It’s fine to have some technical debt, like having an outstanding balance on a credit card, and sometimes you can pay off the interest, i.e., apply a patch; but there comes a point when you need to pay off the balance. This is when you need to revisit the code and implement a section properly; and hence pay off the debt.

There are several reasons you accrue technical debt, one of which is lack of experience and inferior skills by the coding team. If the team doesn’t have the right understanding or skills to solve the problem, it’ll only get worse.

How can you help solve this? I’m a strong proponent of the education you can glean from attending a conference, whether it be Kubecon, Next, DEFCON, or AWS re:Invent, which I just attended. These are great places to sit down and discuss things with your peers, make new friends, discover fresh GitHub repositories, learn from experts, and hear about new developments in the field, possibly ahead of their release, which may either give you a new idea or help solve an existing problem. Another key use case for attending is the ability to provide feedback. Feedback loops are a huge source of information for developers. Getting actual customer feedback, good or bad, helps shape the short-term to long-term goals of a project and can help you understand if you’re on the right path for your target audience.

So, how do you get around these accrued debts? First, you need to have a project owner whose goal is to make sure the overall design and architecture is adhered to. It should also be their job to make sure coding standards are adhered to and documentation is created to accompany the project. Then with the help of regression testing and refactoring over time, you’ll find problems and defects in your code and be able to fix them. Any rework from refactoring needs to be planned and assigned correctly.

There are other ways to deal with debt, like bug fix days and code reviews, and preventative methods like regular clear communication between business and developer teams, to ensure the vision is implemented correctly and it delivers on time to customers.

Another key part of dealing with technical debt is taking responsibility and everyone involved with the project being aware of where they may have to address issues. By being open rather than hiding the problem, it can be planned for and dealt with. Remember, accruing some technical debt is always going to happen—just like credit card spending.


Nice read, thanks a lot for sharing.

Level 14

Thanks for the article.  What seems to happen just as where they'll fix the original mistake, but only to take away key features or create more faults.

Level 13

Thanks rorz​, good post.  This is so true and can happen in a myriad of ways, some of which aren't always visible.  This came up yesterday re: APIs on the ELI5 word of the day.  Patrick mentioned how often someone lays a REST API over the top of the old CORBA code.  The end user can't figure out why the thing is so slow, and it's all because they didn't solve the problem properly by rewriting the API to modern standards.

Level 9

Nice read.

Technical debt doesn't just apply to software/coding.  It can also apply to hardware/infrastructure.  Luckily this technical debt is usually easier to "payoff" and correct.

Level 15

This happens a lot. It can also be caused by tight schedules or lack of funds - same as the credit card.


You stimulated my thoughts .. I remember several situations where the lack of experience and inferior skills by the team caused the problem to get worse.  Technical Debt!!  Thanks for the share!

Level 12

I have heard of Solarwinds customers still using software past end of life, running it on Server 2008 or even Server 2003. And I understand the vulnerability WannaCry exploited had been patched months before this ransomware was released.

It blows my mind how many people don't update software!

Level 12

thanks for the article

Level 10

So very true. If only proper regression testing was undertaken.

Level 10

Putting lipstick on a pig comes to mind. all they have done here is make it twice as complex to solve later (if ever)

Level 10

Yes hardware debt can be easier to both see and solve but also more financially costly (depends on payment model) this usually appears when the hardware team don't understand what is required of them or their infrastructure and just order the latest shiny and new box without understanding the problem they need to solve. This reminds me of a customer who ordered a replacement VMware replacement environment based off of their current usage plus 10% and he was completely unaware that the application had abandoned the aging infrastructure to run in the cloud in hope to return when the next buying cycle came around.Well I think you can see what happened next; resume generating event!

Level 10

Yup spread the word Microsoft EOS and sec updates 14th Jan 2020. One of the reasons I know of that people don't patch is the fact that their application stack is just so fragile when any LOB application should be as bulletproof as possible not made of glass

Level 13

Thanks for the article