Sometimes all you need to get the job done are a couple of poles and some duct tape. You can make an emergency stretcher out of that and could perhaps save a life. But duct tape and poles is not what most of us would hope to see when an ambulance arrives. Just because we can do things with whatever we might have on hand doesn’t mean that it is always the right approach. Our duct tape stretcher probably wouldn’t work well if we tried to integrate it into our healthcare system. The same applies to web sites.
What is technical debt?
One of the things we come across frequently in our work are sites or parts of sites that were built in a hurry or out of necessity, with a minimum of resources, and without an eye toward best practices or security. Often these sites become essential to the organization that launched them, and for a time all goes well.
But as new features or updates are built on top of this increasingly unstable foundation, your site sinks deeper into technical debt.
Technical debt occurs when organizations fail to invest in refactoring, code cleanup, and security either at the outset or as new features are added. When this happens, problematic code begins to pile up, and it becomes increasingly difficult to understand how certain sections of code affect others or if code is even still being used.
The easiest way to deal with this in the short term is to just keep heaping on technical debt, but the long term consequences are exponentially increasing instability and unnecessary complexity that will negatively impact your site’s performance.
Addressing the issue becomes even more expensive later, when the developer has moved on and you no longer know where the bodies are buried. Wikipedia describes technical debt as the “eventual consequences of poor system design,” but in the wild, wild web, it’s often caused by no system design at all and the myopic insistence on scratching immediate itches without concern for the system as a whole or a clear understanding of the long term consequences.
So what should you do about it?
If this sounds like your organization’s website, stop and step away from the keyboard.
Before you do anything else, you must address your website’s technical debt. This can be a very difficult case to make to your stakeholders, who will always prefer new features over fixing up your old ones.
Be sure it’s very clear to your organization that you have a real mess on your hands. As much as you can, show exactly where your site is broken and how those effects ripple out.
Make the case that removing roadblocks now will ultimately save time when your site is in order and new features become easier and faster to implement.
Show that paying down your technical debt will ultimately save your organization money in the long run when you’re only paying for adding new features, rather than for working around old issues as well.
Most importantly, tie your case to your mission. Paying down your technical debt isn’t just about tidier code and a faster site. It’s about being able to better serve your community with more efficient technology, and it’s about saving time and resources that can be invested into more effectively carrying out your mission in the future.
And if your website is in over its head, hire professionals to help out. Don’t keep trying to work with band aid solutions. That’s how your site got here in the first place. It’s time to end the cycle.
I made a new friend at this year’s NTC conference who had recently been hired to manage the web sites of a well established New York City nonprofit. She knew exactly what she was taking on, and though it’s always tempting to continue accumulating technical debt, she made the case for the long-term value of adopting a more sustainable strategy, and she reached out to us to help.
We take technical debt seriously and have built our support service to minimize it. That’s why include maintenance as a foundation to our support offering. Our maintenance service keeps your codebase robust and secure. Whenever a security update is released, we test it and make the update for you. There is no need for you to file a ticket, send an email or lift a finger. In addition to our maintenance service, we also offer support hours that you can use to have us add features or fix bugs, but because your support hours have a maintenance plan as their foundation, you know that our development always builds upon a clean, stable, secure codebase.
The best way to deal with technical debt is not to accumulate it in the first place.