One of the things I often have to do in my role is to review existing Content Management Systems (CMS) which have been heavily customised or contain applications built from scratch. I always reckon I can tell whether a system is worth keeping just from the number of lines of code it contains. The more code the more likely it is that it needs to be replaced. These days most projects are migrations or reimplementations it’s quite rare to see a true green field project. Even on these I find I’m quite often brought in to find out what’s gone wrong. My heart always sinks when I see a project with lots of custom code. I can almost guarantee that the project will be a failure or at least hugely delayed based on the number of lines of code which have been written.
I’m not saying this applies to all systems. As we all know many Financial systems still run on Cobal and contain lots of code. Apparently they’re too complex to migrate. Google is estimated to contain 2 billion lines of code and that seems pretty successful. But here I’m talking about Content Management Systems and these are not like building applications from scratch. In a CMS you get a lot of functionality and features built in. Security, Workflow, Metadata, Search etc. it all comes for free.
The amount of code in a system is often a result of several factors such as:
- the age of the system. Typically new features are added but very rarely are old ones removed;
- the complexity of the system;
- the amount of customisations; and;
- the number of integrations.
I’m hesitant about the last one because the number of integrations shouldn’t affect the amount of code. If the integration pattern is correct you should be able to add more systems into the mix with just configuration rather than large scale coding.
So what’s wrong with lots of code? Logically the more lines of code you write the mode bugs there will be in them. From my own experience I don’t think it’s a linear scale I think the bugs rise exponentially. The more code the more interactions there are and the more things that can go wrong. That’s why smaller projects have a far greater success rate than larger projects.
But don’t get me wrong. I not saying that we shouldn’t attempt complex projects and I’m not saying that there aren’t successful large projects out there. What I am saying is that we should break things down into small components and small modules and use them as our building blocks.
The other issues with too much code are that it’s likely to be much harder to extend and maintain. From a Content Management point of view lots of custom code tends to encourage single use systems and a lack of sharing of information. This is akin to a silo approach although often the information can actually be located in the same repository but because of the classifications and complex implementation are effectively siloed from other content. A virtual silo if you like.
So how do you avoid it writing too much code? The most obvious way is to use the built-in functionality of the platform or off-the-shelf modules. This can greatly reduce the amount of custom code which you write. Even creating your own custom modules is a help. If a module has been designed to be reused and solves a specific problem it can be tested independently and verified. It becomes less like custom code and more like an off the shelf product.
Of course some of the bigger CMS platforms take this to extremes with products such as Drupal containing vast numbers of community developed Modules. Here the issue with using the modules are how well they are maintained and how they fit in with each other.
A clear design and focus on reuse will also help to reduce code. One of the systems I’ve been looking at recently is actually a two page application. It’s used by several departments and unfortunately the “two pages” have been reimplemented for each department. What could have been a fairly simple application with shared functionality is now seven separate applications.
This leads onto the last point which is to ensure that features can be switched on using configuration rather than custom code. Configuration based on the functionality rather than the department using it is the way to go. This way a feature isn’t tied to a particular used.
Developers always like developing and writing code, it’s what they do. Sure there will be cases where writing a little bit of custom code can save installing several modules but in general with Content Management systems each piece of custom code should be justified and scrutinised and avoided wherever possible.