“Technical Debt” is a recognized concept in software development and other technology-based enterprises, but it affects most businesses to one extent or another — and it matters in marketing as well, to the extent that you view your website as a part of your overall marketing effort. If your website is revenue-generating through online sales or other business functions, the connection is even more direct.
What is Technical Debt?
Sometimes referred to as design debt or code debt, in a nutshell, technical debt refers to future investments that must be made in your software. Like financial debt, it’s not a bad thing in every circumstance, but in all cases, it can become an existential threat to the business if ignored. Over time, technical debt can accumulate in the same way that financial debt gathers interest, and eventually a time will come when it needs to be repaid in full.
There are three types of technical debt, each incurred in a different way.
Deliberate Technical Debt
Sometimes during a development project, work is deferred for later, for a variety of reasons. This may be done in order to launch a minimum viable product (“MVP”), to meet a deadline, or to meet budget constraints. Often this type of technical debt is referred to as tomorrow’s work resulting from a shortcut today. This type of debt is deliberate, so the risks and rewards are usually understood, with some appreciation of the time horizon within which it needs to be resolved. In some cases, of course, the horizon can be quite distant.
Technical debt incurred deliberately may be prudent or not, depending on the circumstances and reasoning. Basically, the difference is in knowing about the consequences and either planning for them or ignoring them. Done deliberately, it can be a useful tool.
Accidental Technical Debt
Accidental, or inadvertent, technical debt can arise from outdated design or architecture, or from code written in an inefficient manner – code that is redundant (repetitive), mediocre or sloppy, or which doesn’t follow best practices can be categorized as technical debt since it will eventually need to be “cleaned up” or refactored to function optimally. In some cases, this means it will need to be rewritten. In these cases, the fact that it works today is no guarantee that it will function properly tomorrow.
Sometimes technical debt of this type can be the result of development teams “working it out” as they go due to changing requirements or to finding better ways of doing something partway through but pressing on with the inferior solution regardless. This isn’t always the result of an inexperienced development team, but can easily happen under those circumstances. Note that technical debt of this nature isn’t necessarily from choosing one of two equally valid approaches.
Software Entropy
Software entropy is largely explained by its other, more informal, name: “bit rot.” Some technical debt happens over time. Technical debt of this sort can accumulate as changes and additions over time create unnecessary complexity, sometimes with work being done by different developers over time with different approaches or who make changes without fully understanding the application’s architecture.
Sometimes the application can just stop working or present new bugs with no apparent explanation. In some cases, the underlying architecture or software libraries may no longer be maintained or reach their end-of-life, or may no longer be the best option for a variety of reasons. Platforms or architecture which may have been in favour when the application was developed may become outdated. As with the case of some very large systems written in COBOL, it may not be cost-effective to fully replatform them, but this does not mean that the technical debt does not need to be serviced in other ways. This ensures the application remains well-managed and the application remains functional for its intended purpose.
Technical Debt & Your Website
As web standards improve over time with upgrades in different architectures, libraries, or other dependencies including not just the website itself, but other environments from the webserver to the user’s browser. If the site was programmed in PHP, for example, updates to the programming language over the past few years have made some of its older syntax invalid so that it will cause errors as the server environment is updated to ensure the latest security patches are applied.
Sometimes programming languages or tools fall out of favour and become more expensive to maintain due to the reduced availability of experienced developers. COBOL is a familiar example, but Flash is basically dead online, languages like ColdFusion are rarely used anymore, and even good programming languages like Perl and Python are not as popular as PHP, hence can be harder to find support for. (Think of it this way: it didn’t matter that Betamax was the better videotape format.) Databases like Microsoft Access have been used on websites in the past, but older versions may not have an upgrade path to the current one.
Some website software may be updated without an upgrade path from a current to a newer version. Content management (CMS) software like Drupal intentionally makes no effort to ensure backward compatibility or provide an upgrade path from one major version to the next (minor versions are updatable), and the same can also be true of older versions of the Joomla! CMS. Fully custom applications can make this even more difficult. Eventually, upgrades will be necessary for security reasons that will introduce breaking changes for a website — unless the site is updated periodically to keep it as current as possible. This is the best strategy for avoiding a sudden unexpected surprise.
WordPress & Technical Debt
As WordPress specialists, managing technical debt is one of the things on our minds in our selection of tools. Web hosting that includes regular WordPress updates is an important part of this. Keeping software updated as new versions become available means each update is smaller and less disruptive, meaning it presents less risk of breaking your site than waiting for an extended period of time until several versions must be skipped to reach the latest version.
The WordPress development team’s philosophy places high importance on backward compatibility and ease of updating websites. Given their market share of the CMS environment, this is fairly critical to the functioning of millions of websites every day. Using core WordPress functions within custom development helps ensure that as the core versions of WordPress are maintained and updated, custom themes and plugins will continue functioning as designed, so using experienced WordPress (not just PHP) developers becomes important.
When we first began using WordPress (or rather, its predecessor), its availability under the GNU General Public License, or GPL, was a major deciding factor. This software license means the source code for the underlying application is distributed freely for people to use, modify, share, and contribute back to the project. Today WordPress, like Linux and other software like BIND, Apache, Sendmail, Netscape Navigator, NGINX, MySQL, and some of their successors (all of which are similarly licensed) has development being sponsored by major corporations, and without it, the worldwide web simply would not function as we know it. How does this relate to technical debt? If you’re using WordPress, you literally have more than one-billion-dollar corporation contributing to the maintenance of your technical debt, for free. If your site is well-built and continually updated, it will keep working into the future, but even if some component needs replacing, the core functionality will serve you well into the future without having to rebuild from scratch.
If you’re concerned you may be accumulating technical debt with your website, let’s talk. We can assess where you’re at and make a plan to either eliminate or keep it in line.
