A few years ago, SensioLabs performed an analysis of PHP-driven projects and their levels of accrued technical debt. The results were shocking, to say the least. But first, let's take a step back and define what technical debt means. For many marketers and executives this term is likely something they are not familiar with, but the concept is as fascinating as it is important, so it warrants a little explanation.
Defining Technical Debt
According to Techopedia, Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution". This means in many cases that technical debt is the crud that is developed in response to immediate needs. This can be the quick request you have for your development team because of an urgent business requirement, or the emergency patch to your website in response to a security flaw. Whatever it is, chances are that if you need it fast, it isn’t the most elegant coding practices that are getting the job done.
Like financial debt, technical debt can be both a good and bad thing. Obviously, leveraging debt is a great way to finance expansion or acquisition of new properties or equipment. Likewise, making quick fixes to a piece of software can be a good thing if they aid the overall good of the company or application. With urgent fixes for example, an urgent fix to secure a platform is always the right choice.
But in keeping with our financial debt analogy, concern must be given to the concept of unpaid debt. Your financier expects their bills to be paid and likewise, your software does as well. The quick patch that then is built upon for many years quickly becomes a problem that may not be easily resolved. Over time, quick fixes and hacked solutions become more and more unstable as they grow and are even further expanded upon. Eventually, much like a market bubble or a business that becomes insolvent, software can blow up and be either unstable or incapable of being improved upon.
Should You Worry?
In getting back to our example, the SensioLabs study, we can see that technical debt is becoming a massive concern for the most used platforms available today off-the-shelf. WordPress, the leading CMS available for free download, has enough debt that it would take 20 years of labor to fix. 20 years! Drupal 8, the latest release, had 3.7 years of technical debt. This report is from 2014 – Drupal 8 wasn’t even officially released until a year later.
Should users of those platforms worry? The arguments on both sides are similar to those of the debate about our nation’s debt, where some people are less concerned than others. To an extent, technical debt is a normal side effect of team-based software development. Eventually, in the long run, it is somewhat inevitable. If you are on WordPress today and your site is stable, then I wouldn’t go running for a developer because of fear over how much debt the platform has already built in.
But, users considering a platform shift should take careful consideration! From day one, where you install the software, you have 20 years of mess to clean up. This concept is completely astounding to me. That you can install software from the provider, in this case the open-source community, and from the first moment require 20 years of effort to clean up the code. In this case, doesn’t the debate for custom software seem a bit more relevant? How can your organization gamble long term with a platform that is already so far behind? If we take a quote directly from the blog post at SensioLabs: “If this [technical debt] value increases in time, the technical debt is out of control and using that project may be risky for companies.” And this is the precise concern we tell all enterprise clients when they are vetting new platforms. To risk the safety and security as well as the long term reliability of your web platform to a product that is so flawed is a risk that must be considered.
Now, I know the WordPress supporters will throw out some arguments refuting these points. They may say that being the oldest and largest platform is reason enough to justify these findings. But in reality, even that is a bad excuse, as it simply highlights the lack of modern coding within the WordPress platform. In the case of open-source CMS platforms, it turns out that choosing them are great for starting from behind. Who would ever want to do that?
Frameworks versus Platforms?
Another interesting take away are the differences between platforms and frameworks. We’ve discussed in the past the differences between coding platforms and frameworks, where frameworks are built for custom development projects and platforms are built to appease the masses with universal workflows and functionality. According to this analysis, Symfony 2, which at the time was 3 years old since their initial release, accrued only 8.8 weeks of technical debt. The worst framework was CakePHP, but even that was relatively clean when compared to off-the-shelf platforms. Since these frameworks serve as the foundation of almost all custom developed applications that utilize the LAMP (Linux, Apache, MySQL and PHP) technology stack, this level of cleanliness at the codebase level shouldn’t be overlooked by those pondering how to build their next project. There is a value to knowing that you are starting with a relatively clean slate, as opposed to already outdated bloatware.
High Debt = Unpredictability
I would assume at this point that many marketers are wondering how the technical debt within the code of a platform can affect them. After all, they are just end users and their website or project may seem relatively benign, surely nothing that will push the limits of the platform in question. But, that is simply a distraction from the real issue. Platforms with high levels of technical debt carry with them a much larger risk, such as the risk of security breaches, risk of unknown updates that are required, and risks of an unknown development cycle.
The largest issue that comes up in conversation is usually surrounding security. With large code bases that can carry hundreds of thousands of lines of code, securing the platform becomes increasingly difficult. In fact, much of the 20 years of technical debt within WordPress I’m sure is in response to security breaches and gaps.
Add to that uncertainty the inability to predict updates to the platform, or what the future codebase will look like. Many updates and code changes mean constant updates, and redevelopment of trouble areas. That unknown development cycle makes it hard to plan when one should invest in deploying these platforms. The most recent example was the development cycle of Drupal 8, which took many years. Website owners and managers were left wondering if Drupal 7 was a decent place to invest their time and money, unsure of when the next version was being made available. Many opted to simply leave the platform, which was redeveloped from the ground up for precisely the reason for this article: an abundance of technical debt!
Is This a Bubble?
I hate to use the term bubble, though I have used it in the past. But, it’s hard to find another term to describe what is happening in the software world. Eventually EVERY project will need to be recoded, and WordPress is definitely due for such a shift. This has happened before with other platforms. Drupal 8, as we just mentioned, is a drastic redevelopment versus Drupal 7. With that possibility in mind, when the massive redevelopment happens, how many of the millions of WordPress users will carry through and redevelop their site knowing that it will have a substantial cost to them? After all, most people choosing WordPress are using it because of budgetary reasons anyway. How will the internet be affected by millions of websites running software that is no longer supported?
Sure, call me alarmist, but what other possible end can happen? Not to be philosophical but we all know the saying: all that begins also ends. And likewise, every one of the millions of WordPress sites in existence will have to go through a massive transition when that redeveloped platform is made available – whenever that may be. Are those website owners prepared for this shift?
Is enterprise software (or closed source) better?
I had the technical debt conversation with a prospect recently. After some time, she came to ask if enterprise software was better. Would an AEM installation have less of a problem with technical debt? The answer is – who knows!? Reason being: most enterprise platforms are closed source. The reason you pay obscene license fees is to not worry about such problems. So, you can on one hand be assured that it is a level of stress you may not have to worry about. But on the other you can be worried that perhaps the platform isn’t under control, and ultimately you’ll be forced to migrate to a new release when they redevelop. There simply isn’t any way to know for sure, and trust me when I tell you: your sales guy won’t have any idea and even if he did, he wouldn’t tell you!
Beware of Compounded Debt
One important thing to look out for isn’t even the technical debt of the platform’s codebase itself. You can’t even really see that – it’s much like the national debt in that it’s a macro problem of which you will surely be subjected to the consequences of but you may not have any direct knowledge or understanding of the problem. Compounded debt in the case of off-the-shelf platforms will be the decisions your developer makes in customizing the solution for you. This is the highest risk scenario to be conscious of. A developer who does not have a grasp of the software in use can easily make bad decisions that may plague you for years to come.
I’ve seen examples of this throughout my career, and in that time the worst scenarios have often been when off-the-shelf software is involved. We’ve discussed the differences between real developers and platform customizers before, and this is the area in which underqualified customizers can do serious long-term damage. Consider this the riskiest debt of all – kinda like a high-interest credit card – it charges obscene interest rates and can get out of control quickly and easily.
Luckily you can avoid this with qualified development help. Don’t be so fast to settle on the lowest bidder and make sure you review the longevity of their past projects – not just the simple screenshot portfolio.
Conclusion – On a High Note
I know much of this post sounds alarmist. The sky isn’t necessarily falling yet, but, the issue of technical debt will be catching up with these platforms sooner rather than later. The evolution of software, especially in the content management space, will require changes that past platforms won’t be able to accomplish. Now more than ever, website managers and marketers should carefully consider all options on the table available to them, to avoid being stuck on a platform that will either no longer be supported or require a massive redevelopment effort shortly down the road.