Matthew Cox Team : Web Development Tags : Technology Web Development Programming

The CMS is not the be-all, end-all

Matthew Cox Team : Web Development Tags : Technology Web Development Programming

I’m not a big fan of throwing a CMS into every project you work on just because there is some text that needs to be managed on the site. Let me give you an altogether too common scenario.

You gather the requirements for your project, and based on those requirements you choose a CMS that will fulfil as many requirements as possible. You start learning about this CMS, you watch introductory videos and move quickly into reading every best practice guide that you can find. You are not an expert but you have diligently researched the right way to use the system. You then build, which goes relatively smoothly, you learn some new things along the way, but you are generally happy with the project. Then it happens. Something breaks, or slows down to an unacceptable limit or 1 in every 1000 requests causes something unexpected.

You start by researching the issue, you turn up some mentions of the bug from several years ago, but that can’t still be the same bug that the CMS devs still haven’t fixed can it? You try all the suggested remedies you can find but nothing works. You reach out to the CMS devs who initially provide a few helpful suggestions, but when those suggestions don’t fix the issue they mysteriously go silent. So finally you roll up your sleeves and figure I’ll have to fix this myself.

Suddenly you realise what has happened, to get out of having to create a couple of text entry fields for the client to use managing content, you have inherited a codebase of hundreds of thousands of lines that just doesn’t work, at least not the way you expected or needed it to work.

This should be the nightmare scenario, a scenario that almost no dev has to deal with, but in my experience it’s all too common. So is the solution to abandon all CMS’s forever? No, of course not, but you need to mitigate the risk when inheriting the technical debt that comes along with a CMS.

To do this you first need to ask yourself if you really need a CMS on your project. As my admittedly pithy example above suggested, at its most basic level a CMS is just a collection of text boxes that allow a client to manage content on their site. There is no reason to imbue CMS’s with any greater significance than that.

The likelihood of experiencing the nightmare scenario is inversely proportional to how closely your project matches the standard use cases for the CMS. For example if you want to use wordpress to build a blog I’m pretty sure you will be fine, however if you want to use it to drive an ERP solution you’re going to have a bad time. This has the nasty side effect of stifling innovation and change by forcing developers into the same patterns of website development.

While overall, an established CMS is a boon to the majority of projects, they do have their downsides. CMS’s do a lot more than just manage content, which is great if that’s what you actually need, but if all you need to is words on a page you are best avoiding the increase in complexity they add to the project.