Businesses and industries develop simple terms to effectively and quickly communicate complex concepts in a way the participants in discussions can understand without getting sidetracked about the main conversation. A term that is commonly used regarding technology is Technical Debt. Most businesses notice as their tech stack grows, deployment of new features takes longer, are more prone to bugs, and implementation becomes more complex. It’s used to describe what impacts the growing complexity of deploying new features in enterprise systems, but what does it really mean?

We’ll look at:

• Technical Debt’s common definition.
• Technical Debt’s origin.
• Factors that play into technical debt.
• What can be done to reduce technical debt.

Technical Debt’s Common Definition

Technical Debt is commonly defined as the cost of rework caused by employing the quickest solution as opposed to the best solution for the long term. This definition leaves a lot of room for interpretation but has an overall connotation that the software developers took shortcuts. While it is a fair assumption that some shortcuts were taken to save time, there are a ton of different reasons why technical debt occurs that is not solely on developers.

Technical Debt’s Origin

Technical Debt was first introduced as a concept by Ward Cunningham to explain to a financial executive how the software works in terms that make sense to financial experts. He told them:

“If we fail to make the program aligned with what we understand to be the proper way to think about our financial objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.”

It was recognising that software engineers don’t always recognise the full vision for the code at the beginning and as they progress through development and the growth of the software, there will inevitably be more information than there was at the beginning. He further explains that the rework occurs due to the increased knowledge. This tells a far different story than the common definition. This suggests we should take a closer look at…

Factors that Impact Technical Debt.

We’ve already discussed potentially bad code and a lack of understanding, but there are other aspects that impact technical debt, including a rapidly changing business environment or unexpected integration issues because the software was built in a vacuum.

Rapid Change

Businesses are always evolving and a major change might occur so quickly that the software that was built is no longer relevant to the business needs. While we encourage people to use cloud resources due to the substantial advantages over on-premise servers, I could see organisations having issues with software that was built late last year that required employees to be on-premises to use it. Many organisations would find that software unusable due to the changes brought by COVID-19. We’d then have to alter the software for remote access.

Unexpected Integration Issues

While it would be preferable if this isn’t the case, sometimes software is developed without truly communicating the business goals. If a software is built for standalone use, it may not be as easily integrated with other pieces of the system. To an outside observer, it would appear that the software that was developed does not meet the objectives. When this occurs, reworking the solution is inevitable.

Ease of Refactoring

Writing code is a mix of art and science. How it is written will impact the ability for future changes. Writing it in a way that is easy to read and alter as needed will reduce technical debt over time. One of the easiest ways to write easily refactored code is to start by specifying what is the bare minimum the code has to do to be functional, then code only those aspects.

Reducing Technical Debt

There are two primary ways of reducing technical debt, increased planning at the beginning or structuring projects where you consistently refactor. Let’s discuss when to use each solution.

Increased Planning

Increased planning works phenomenally when you are talking about a static asset. Many construction and home repair companies can get away with using this approach for their customer-facing websites because their services tend to stay basically the same for long periods of time. In these scenarios, a development company can sit down and discuss what features they’d like on the site, plan it really well, and then build it. Future changes are typically things like wording or adding new pictures, which can be accomplished without major coding changes. These tend to be small projects and don’t have many features.

This won’t work well if you have an application that has routine changes or services in a rapidly changing industry. The planning process takes too long and by the time everything is built the opportunity could be gone. That is why most software development companies…

Plan for Refactoring

I mentioned this previously while discussing the ease of refactoring, but let’s go into more detail. Refactoring is making changes to the software as needed to make it work even better after you have more of an understanding of the business purpose it is meant to achieve.

A common technique for planning for refactoring is the red-green-refactor process. Red is setting out the testing requirements for what qualifies as passing software. Green is developing the bare minimum. Then refactoring is the process of making the software work better.

In the red stage, you need Xero to integrate into your current financial records, so you set the testing requirement as to whether Xero can read and write to your database.

In the green stage, the development is done in a way where Xero can read and write to the database, but that another developer can come in and quickly tell how it works. You test that it works as you requested and this stage is done.

A week later you decide you want a Point-of-sale(POS) system to also be able to read and write to the same database and Xero users to be able to see the changes. So the refactoring stage begins.

During this portion, we’d look at the previous code and see if any of it needs to be cleaned up. Then we’d make changes to integrate the POS while making it a point to confirm whether we can use existing code for both systems. If we can, we use the existing code to prevent duplicating parts of the code in the system. Then once the new coding is completed, we test both Xero and the POS to verify that both work as intended.

As you can see this process works much better for applications that will have regular changes or when routine updates to the software will occur. It gets new functionality out quicker, allows the system to grow with your organisation, and is easy to follow because it is coded with the intent of adding new features.

I hope this look at technical debt and how to reduce its impact on your systems has helped you understand how to reduce its impact on your organisation. Planning for refactoring fits well with Flying Donkey’s agile development strategies and makes it where our clients’ systems can grow with them. Check out our development page to learn more about how we approach projects.