On Technical Debt

Technical debt — a term used to describe how changes to functionality lead to added cruft within site code — is almost always a function of change. It’s a necessary evil and a natural consequence of progress.

So, if your site never changes, it can’t accumulate technical debt, right? Wrong.

Even a completely static site will accumulate technical debt over time if not cared for and maintained. The site might not change, but the world it exists in does. Infrastructure, technology, and even basic conventions evolve over time, and your site needs to evolve in lock-step. Failing to maintain can lead to issues and insurmountable debt. You may have to “declare bankruptcy” and rebuild from scratch.

Code that is secure today is not necessarily secure tomorrow. New attacks are devised, new vulnerabilities are discovered, and risk grows as old code ages unobserved. It’s important to keep dependencies, run times, and hosting software — really, the entire software ecosystem surrounding your site — up-to-date. It’s also important to audit your code against new attacks and vulnerabilities. Fixing these over time is relatively easy, but fixing a mass of these all at once becomes very difficult.

Sites considered accessible today may not be accessible tomorrow. Accessibility evolves as our standards and assistive technologies change and grow. Are you regularly monitoring your accessibility against current standards? You should be.

Even the aesthetics of the web constantly evolve. Like any design, web design is a language that communicates meaning and intent. For example, years of web browsing have taught us that underlined text signifies a link. This is part of the language of the web. And, like spoken languages, this language changes over time to suit new needs and express new ideas. Beyond just “looking dated,” a site that doesn’t keep up with current design standards may communicate poorly or inaccurately. Users face minor, mental hiccups navigating structures that don’t look or function the way they’ve come to expect. If there are enough micro-interruptions, they may move to other sites they find more intuitive.

Indeed, code doesn’t experience “wear and tear” the way a car engine does. New bugs don’t just spontaneously appear. Variables don’t age. Bits don’t rot. But the world around the code churns constantly, and stagnant code that doesn’t respond accumulates technical debt. And as the debt grows, it compounds. It is better to address it on a regular, ongoing basis than allow its unchecked growth and the inevitable bankruptcy that follows.