CMS Is Not At Fault, As Much As Wrong Choice Is

Clay has insightful thoughts about why CMSs don’t work. More often than not, off-the-shelf CMSs become a hurdle in the things we want to do our way. However, I do not think it is only the CMS to blame.

I think the most common cause of CMS failure is the feature-driven selection. The management is too keen to select tools and finalize the budget to spend time on requirements. Why? Because it is a lot easier than discovering the requirements. Unfortunately, by the end of implementation, when we sit to use it, we realize that we have only managed to kick the can down the road.

Like Clay says, frameworks are the next choice. If you find CMSs too stubborn for your needs, frameworks can help you build your own CMS. But, like a CMS, a framework too has its limits and recommended ways of doing things. I have seen instances where it has been tedious to build what we want on frameworks. Soon, you venture into hacking and it gets painful to maintain upgrades and install security patches.

And if we give up on off-the-shelf frameworks, we create our own. Though it might seem a waste nowadays, there are many popular sites around us which have done that. I wonder if any off-the-shelf CMS or framework would have worked for Facebook.

I do not think any CMS or framework sucks. I think they do not work where they are not meant to be used. I try to follow a series of steps to avoid this:

  • Try to get a handle on the core requirements as early as possible. We can never be sure of it, it is only a feeling that comes out of discussions with the team. Of course, this is a deep topic in itself, and deserves its own space.
  • If we (the team) feel comfortable with most of the requirements, we look for a suitable off-the-shelf CMS and use it.
  • If we do not find one, or if we feel that a good portion of the requirements are uncertain and can change, we go for a framework.
  • If we feel that the requirements are really so unique that it warrants its own code base, we get ready to do that.

In addition, coming out with testable code base, and UI if possible, quickly helps us in validating our tool selection. Because it is only usage of the end product that can tell us if we have the right tools at our end.

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.