I have been thinking a lot about technical debt lately – weird I know, but these are the things you think about when you deliver code to customers that power their businesses, digital initiatives, and websites.
I am also celebrating with our IT Team the decommissioning of our datacenter footprint. For decades, we had physical servers running in a local datacenter. As we deployed new projects to AWS; we let our servers and equipment age out, running fewer critical services on it over the years. But back to the point…
What the heck is all this technical debt?
Traditionally, technical debt means that choosing a quick and easy solution now reflects an implied cost of additional rework down the road. Without recurring updates, any software can incur technical debt over time.
It’s a bit easier to think about technical debt in terms of physical infrastructure or hardware. Think of your phone or laptop. While it may be shiny and new now, in a few years it’ll need more memory to even browse the Internet (we will cover PWA’s and SPA’s in another post)… or the phone may need to be replaced altogether.
What kinds of technical debt are out there?
Here at Atlantic BT, we have to think not only about technical debt in the cloud servers we run, but also in the code that powers the web-based software we build. The technical debt in code is a bit more abstract to think about.
Over the years, we have learned many IT tricks to keep legacy code stable, maintain security, and keep applications resilient. Implementing these tricks can be highly effective in extending the lifetime of the application.
However, nothing lives forever, and applying these techniques can be misleading. It’s possible to actually hide the growing technical debt accrued due to advances in the surrounding technical environment.
Technical debt in software design.
There is a lot of talk about the tradeoffs at the software design stage of a project and how that translates to technical debt – while that is where the debt starts, it’s usually easier to manage at that point.
Planning is critical. That’s why we take a preventative step of having developers discuss solutions with a team, write out their feature specifications, and create acceptance criteria.
Technical debt in software maintenance.
The technical debt that I want to focus on is the kind where we don’t invest in properly maintaining software over time and how that builds the technical debt snowball. We all have those skeletons in our proverbial IT closets… those applications that only one person actually knows how to build, deploy, and support. The ones we leave out of our DevOps pipelines because the systems can’t handle infrastructure as code.
This debt builds over time and if not addressed can lead to issues in recovery time objectives (RTO) or recovery point objectives (RPO) in disaster recovery and business continuity plans.
You will incur all sorts of costs: time, inability to deliver business value, security, or reliability. Some of this technical debt may exist in legacy applications where you are also having a hard time finding quality candidates to support or change these applications.
What kinds of decisions create technical debt?
In my opinion, technical debt is simply a tradeoff between money, time, and objectives. It’s like the PM triangle of speed, budget, and quality where you can only pick two options for your project.
These types of decisions will affect technical debt, creating high risk and future costs:
- Not investing the time to bring in a diverse team to design software.
- Not investing time in refactoring something that works to make it more testable or elegant.
- Not spending time on documenting the feature specification and acceptance criteria for a story and jumping right into writing code.
- Not spending time thinking about security.
- Not leveraging real enterprise design patterns to build new components based on legacy decisions.
At the end of the day, technical debt is simple: it comes down to money over time, just like debt in real life.
What can I do to assess my current technical debt?
The best way to get a handle on technical debt is to audit your application stack, IT infrastructure, and business processes. Look for weakness in the observability of the security and health of these items.
With today’s continuous integration systems, it’s fairly straightforward to assess your core code with static and dynamic analysis, Linting, and unit test coverage reporting. There are also many tools to facilitate, such as visual regression.
Microsoft author Paul DiLascia wrote an article that offers these guidelines for good code:
A third party code audit can help you gain insight with a fresh pair of eyes. Assess whether or not your code possesses the above traits, shedding light on documentation weakness (both within the code and in user guides) and other poor coding practices.
A third party can also have conversations with your stakeholders or internal teams around coding practices, software development methodologies, CI/CD, and DevOps.
How do we fix technical debt?
Like any debt, technical debt needs to be calculated before it can be fully addressed. Once the magnitude of the technical debt is known, it’s all about time and money.
Start crafting a plan to address technical debt in core areas of the business that generate revenue, provide your X factor, or support your team.
There is no simple answer, but today’s IaaS, PaaS, code frameworks, and developer tools all provide jumping off points that can mitigate technical debt while allowing you to focus on your core business.
Part of our business is helping you in this area. So if there is any acute digital pain or technical debt you’re experiencing, let’s have a conversation!