Networks

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

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

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.


Ruairi is a technical individual with over 14 years experience in the IT industry, and likes to think of himself as a “jack of all trades.” With experience in everything from networking, security, end user compute, and enterprise application deployments, as well as dabbling in the cloud, he's happy discussing many different areas within modern IT architecture. Ruairi's current main focus is with storage products and associated software, and understanding their associated strengths and weaknesses. He currently enjoys working with the reseller community within the U.K. channel to make sure they have all the necessary technical skill sets to improve and differentiate their business.