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.

Anonymous

Top Comments

  • 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

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

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

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