Why do too many developers love to build CMS from scratch?
I’m going to assert that no genre of software gets rewritten from scratch as often as content management systems.
For some reason, CMS just invites re-engineering. Developers who would never consider writing, say, a source code management system from scratch, have no problem at all forgoing all the (countless) existing alternatives and building a new, custom CMS from the ground up.
Why is this?
Over the last few months, I tried to catalog all the reasons why this might happen. I got through a couple dozen reasons, then realized that most of them were reasons why developers re-write any software. Things like:
A desire to understand the codebase from scratch
A desire to remove all technical debt
A desire to do things “the right way” (as if there’s only one “right way”)
etc.
These things are not specific to CMS. In fact, it turned out that most all the reasons on my list were general to all software, not specific to CMS.
When I refocused the list on CMS specifically, I dialed it down to three big reasons why this genre of software is so prone to re-engineering.
#1: The Basic Functionality of a CMS is Superficial
Whenever a developer envisions themselves embarking on a project, they’re mentally looking for “hooks.” They’re looking for a specific aspect of the project around which they can wrap their intellect.
What part of the problem is…chunky? How will they get started? What will they code first?
CMS provides so, so many easy hooks, because – on the surface – a CMS is not complicated.
You have a table of “pages.” Each has a “title” and a “body.” OMG, we just wrote a CMS!
And this what we think about. The scary thing is that it’s at least partially true. If you come to me with a brochure-ware site, and a reasonable programming platform, I can write you a CMS for it in one hour. Give me Django and an easy problem, and I’ll whip something right up.
The problem, of course, comes when the scope creeps. While the initial functionality of a CMS is easy, the subsequent layers are decidedly not, and you always end up in a race to the “line of regret.” This is the line you cross where it becomes obvious that you should have used someone else’s solution because you’re re-solving problems that have been solved by someone else and you’re no-doubt thinking “ohhhhh, I see why this sucks…”
But we’re not thinking about that at the starting line. We’re thinking about quick wins. And the CMS domain gives us so, so many of those.
#2: Content is Inherently Relatable
To feel like you can build something, you have to have domain knowledge. You have to understand the problem “in the wild” and be confident that your understanding is deep and true enough to be representative of the problem you’re trying to solve.
The fact that we use the web every day gives us the illusion of this knowledge. We’re convinced we understand the content problem because we live in it, all day, every day.
We’re all CMS users. Every one of us uses a CMS every single day when we surf the web. We all understand things like menus, and crumbtrails, and content collections, and everything else that a CMS spits out on a page. We’re all CMS critics. We all think we know what works and what doesn’t. And once you’re an expert user of anything, it’s a very short hop to becoming a critic.
The problem is that developers get to go one more level. This is simple content management, and this is what is broken about it, and I have the skills to fix it.
Developers spend most of their day as users of software that often pisses them off. We spent time on websites which are obviously broken and in need of serious CMS help.
We are surrounded with problems that people pay us to fix, and we’re both capable and all-to-willing to diagnose these problems. It’s like an addict living in a crack house.
#3: Developers Love Frameworks
Give a developer one problem, and he’ll fix two. The fact is, we love solving problems that don’t exist yet. In fact, we often prefer this, because we get all the fun of solving a problem with none of the accountability of actually having a problem that needs to be solved.
And what is a CMS but a framework for content? And what is the web but a collection of content? Therefore, could the average CMS be a toolset to build the core of the web itself?
I’d venture that a CMS is the ultimate framework. It’s the thing on which we hang content, the very soul of the internet. When we build a CMS, we’re not just solving the problem in front of us, we’re making a framework on which people are going to hang the rest of the Internet on. A CMS is site-in-waiting; a bundle of potential energy, just waiting to be unleashed on a new problem. We love this.
When we start coding a new CMS, we’re projecting in our heads all the different websites that’ll be built with this thing. What we’re building is going to be a brick in the wall of this big crazy-ass experiment in communication that’s a couple of decades old now.
But we don’t have to solve those problems right now. Right now, we just have to build this toolset to solve the imaginary problem we’re projecting in our heads, and that’s invariably pretty simple…which takes up back to reason #1.
And that’s why we love to build CMS from scratch.