Technical Debt and Technical Efficiency

Technical Debt: “The Loan” 💰

Within agile software development, one of our key aims is to get working software out as early as we can. This allows us to enable the value for our users quickly (and therefore bring in revenue as a business) and get early feedback to improve and iterate the product in line with customer needs, without wasting time on things customers might not ultimately want.

While we may refactor our code as we go along, this tends to mean that though the software we deploy works as intended, it may not be as efficient as we’d like. These inefficiencies are often called technical debt.

Technical Efficiency: “The Repayment” 💳

It is important to address inefficiencies in our code over time, for a multitude of reasons: To reduce the likelihood of bugs occurring, to make the code base more manageable, and to improve performance, among other things.

Therefore, its recommended that each product at Advanced sets aside a bucket of time in each release period for technical efficiency - refactoring and improving code to “pay back” the technical debt, like a loan we took out in order to deliver the software early. When American developer Ward Cunningham coined the term “technical debt”, this was exactly what he meant - repaying technical debt is essential, much like paying back a loan.

Technical Product Initiatives and Technical Efficiency 👩‍💻

There are some scenarios where initiatives we want to complete at Advanced are technical in nature, for example:

• Replacing a third party component or platform.
• Upgrading to a new version of a framework or integration.
• Changing our authentication methods.

These initiatives are often erroneously categorised as “technical efficiency”, as the end user does not notice a difference in their day-to-day work. This is problematic, however, as these types of initiatives are not related to technical efficiency by nature, and due to their complexity and business benefit, need to be prioritised against other initiatives.

All of these initiatives should be considered like any customer-facing one, and supported by an appropriate business case that clearly quantifies the value of the initiative, and justifies why it should be done. For example, we wouldn’t be replacing a third party component for an abstract reason; we might be doing this because it causes unacceptable performance issues which are affecting the abilities for users to do their work, or the component might be going out of support, putting our entire service at risk.

It is vital that these items are prioritised and analysed in the same way that customer-facing initiatives are, with just as much care put into the business case. Prioritisation is a wider topic, the scope of which extends far beyond this article, but the following should be considered for more technical initiatives, as well as user-facing ones:

• The business risk incurred in not completing the initiative.
• Potential cost saving.
• Potential revenue add, in terms of additional module sales or selling into new markets.
• Customer satisfaction (and therefore retention).

Paying off technical debt is important, and freeing up space in our development teams' capacity by categorising these initiatives correctly helps us to recognise this.