The Cruft Challenge: When It’s Time to Disrupt Your Own Technology
Old approaches that were once seen as innovative eventually fall out of favor and get outmoded by faster, more innovative approaches. Often, it's hard to throw out what works—but what if we were willing to take on the sacred cows and build something better? The parent company of the content management system WordPress recently tried disrupting itself in this fashion—and came up with something truly impressive.
We’re nearing the finish line for 2015, which makes it as good a time as any to look back at some things we’ve touched upon throughout the year.
One of those things was a disaster on the part of United Airlines, which suffered a frustrating glitch caused by its decades-old computer systems. That glitch created some big headaches for travelers back in July, but otherwise faded from view afterwards—effectively working as a reminder that United Airlines relies on a system that goes back decades.
We all have software like United Airlines’ flight-tracking system, software that definitely needs the occasional upgrade, that is built from technology that predates some of your own employees. The hard part, of course, is figuring out how to do it in a nondisruptive fashion.
The problem is generally this: When you have a codebase so old and dated, how do you make the platform work in the context of modern trends? Programming takes a lot of time to get right, and the programming language you started with may not be the one best suited to modern needs.
A platform that many associations are familiar with had this very same problem facing it—a technical platform that, although used by millions of people every single day, is starting to feel a bit long in the tooth. But WordPress has found an interesting away around the problem of datedness, and it’s one that many organizations should look really closely at.
The Weaknesses of WordPress
To understand exactly why WordPress needed to change things up, it’s important to understand exactly how and when WordPress was born. Coming to life during the early years of blogging, the platform grew from the base of an existing platform called b2/cafelog, which had lost momentum after its creator gave up on it.
WordPress founder Matt Mullenweg, in a January 2003 blog post titled “The Blogging Software Dilemma,” wrote about the importance of forward compatibility and a desire to create something that anyone else could work on in the future.
“The work would never be lost, as if I fell off the face of the planet a year from now, whatever code I made would be free to the world, and if someone else wanted to pick it up they could,” Mullenweg wrote.
WordPress ultimately became that thing, and when it finally began hitting its stride in 2005 and 2006 it quickly leapfrogged over the platforms that inspired Mullenweg—TextPattern, Moveable Type, and Blogger. (A sample of what it looked like during that era can be seen above.) And unlike the creator of b2, Mullenweg figured out a way to turn the platform into both his career and a huge financial success.
Ultimately, though, the biggest challenge WordPress faces is that it’s a victim of its own success—the company has a codebase that’s absolutely massive and needs to support more than a decade of plugins, code, and themes—all while working on a wide variety of server bases.
It’s the United Airlines problem all over again, in a way—cruft built on top of cruft on top of cruft. Programming decisions that felt right a decade ago feel much messier in an age where end users expect snappiness, mobile support, and simplicity all in one fell swoop.
Call it “The Blogging Software Dilemma, Version 2.0.”
A Clean Break
The truly surprising part of the WordPress saga is that the open-source project appears to have figured out a way to tackle this challenge head-on.
The reason the company went with this approach was effectively to get a clean break from all the extra junk that had complicated the WordPress experience over the years.
PHP, the base language that controls WordPress, struggles to keep up with modern approaches like Node.js and React from an interface standpoint. While the company had already attempted to take its backend interface and update it for the mobile web, the end result, which first appeared in WordPress 3.8, only highlighted the weaknesses of the approach, according to Mullenweg.
But beyond the desktop apps is the decision by WordPress’ development team to build a REST API for the content management system, as well as attempts to better support modern use cases like responsive images.
“When WordPress adopts modern technologies, the Internet adopts modern technologies,” WordPress project leader Scott Taylor said in comments during the recent State of the Word event.
Learn to Leapfrog Yourself
Few organizations, and perhaps even fewer open-source projects, would be willing to rethink their framework so drastically, willingly throwing out years of work in an effort to modernize their approach so effectively.
But perhaps leaders should be willing to have this discussion more often, with their vendors or even internally. What kind of technical limitations are holding your association’s website or technical platforms back, and what can be done to limit those complications? Is it a matter of embracing newer technologies, or getting rid of interfaces that simply complicate or confuse?
And how often do you need to look at the innards of what you’re building to see whether things once held sacred are causing bigger problems for your business?
Organizations and companies alike that fail to make time for this conversation threaten to get leapfrogged by a competitor with a more innovative mindset.
Automattic and the WordPress team took an interesting approach to this problem, and came up with a pretty great solution: Instead of letting someone else do it, leapfrog yourself. You might be surprised at how easy it is.