Leaping Over Technical Debt Roadblocks in Software Development

By Felipe Rubim

 With similar characteristics to financial debt, the term technical debt was created to explain how those “not so great but necessary” architectural and design decisions that are made during the software development process ultimately become a loan against a project. Similar to a bank loan, these project loans incur interest over the project’s lifetime and are potentially harmful to the project outcomes.

An experienced and skilled high-performance team will identify the potential hazards of technical debt, and understand that every situation where the debt is not paid back in full (or not amortized, to continue the comparison) makes the eventual solution more challenging to maintain and evolve – and ultimately the debt more difficult to pay back.

It is imperative that developers fully understand the types of technical debt in order to avoid increased risk.  Companies must also seek out knowledgeable development teams that can ensure successful management of debt during projects.  Let’s talk a little about the different kinds of technical debt.

In general, there are three types:

• Domain Knowledge: Not knowing the complete business domain at the outset of a project can be detrimental.  As the project continues and more light is shed about the new requirements, there will inevitably be changes to the architecture and design. This lack of domain knowledge directly impacts the project, requiring unnecessary rework.

• Prudent Design Decisions: Due to various factors (e.g. time), the team may decide to use a framework that is not the best for the solution, but that will suit the purpose at that moment. When this decision is made, the team already knows that an update will be necessary so future enhancements will not be impacted, but even with this knowledge, the framework is still implemented.

• Sacrificing Best Software Development Practices: For example, not conducting proper design, code review, unit testing and refactoring when necessary.

As you can see, it is inevitable that most projects will incur some form of technical debt, making measuring and monitoring the risks critical. Smart developers must track technical debt and correlate it with the team’s activities and velocity in the upcoming sprints. The greater the technical debt, the harder it will be to change the application and the more slowly the team will perform. As performance slows, risks increase that the team will not be able to deliver the agreed project outcomes and value on time.

A clear example of technical debt in a project is Internet Explorer 6. With its lack of standards and security flaws, IE6 forced website developers to spend much more than time typically spent developing for other browsers.  In addition, an old legacy system that adds functionalities without taking the proper time for refactoring and redesign is likely hampered by debt. At different levels, all major products that are developed have already accrued (or will accrue) technical debt, making it appear seemingly impossible to avoid.

Overall, it’s quite difficult to prevent technical debt from occurring. In software development, decisions must be weighed against several factors, all of which may lead to technical debt. You can alleviate it though, by looking at the playbook of successful high-performance teams who know you can prevent technical debt from growing by tracking it effectively and taking every opportunity to amortize it or pay it back in full.

When selecting a development team for a project, it’s critical for the stakeholders to ask about technical debt: How has the team tackled it in the past? What is their worst-case scenario plan? By understanding a team’s knowledge of and preparedness for technical debt, the client will fully understand if this team is qualified to take on its project and lead it to a successful outcome.