Unusual Subroutines


The blog and musings of Christopher Allen-Poole

CMS problem

There is a project I've worked on of late. It's a new CMS and I have to say that there is a rather significant and fatal flaw in its design – it requires all developers to work in the same data set.

Now this is by no means the only time I've seen something like this. I would be lying if I didn't admit that this has pretty standard fair for the industry, but then so was Subversion, and we all know how terribly that turned out. I will say that this is the most egregious example (as the underlying data architecture does not support even a cursory form of export) and the last time I encountered it I was also able to mitigate it by creating a truncated version of the data locally.

The problem with any form of shared content architecture is that means that for every developer there is a 100% chance that some or all of their data will be altered, sometimes dramatically, sometimes catastrophically, while still writing the same code. That isn't how good code is created, and it is very much why there are such things as unit tests which try to avoid these very variances.

The problem is pretty basic and, I think, pretty clear: instead of there being a solid if-then-else construct, you suddenly find yourself writing code against an ever-shifting base. Data structures are re-written, object models distorted, content is removed, and it becomes impossible to determine whether a recent modification of the the code is at fault or whether someone did something stupid with the environment.

I'm also confused on how there is an expectation that such a system can be well replicated to later environments (in our case it couldn't). If we can't build something isolated on a local instance, how do we expect to be able to build something to QA without pollution? My suspicion is that such a system wouldn't even allow users to support even a basic upgrade and deployment pattern (and in this particular case, it does not).

Now a counter-point might be that multiple licenses for developers is something which is very expensive, and that may be the case. It might be more expensive to have each developer have a sand-boxed version of the content, but is that more expensive than the cost of a senior developer who has to then support the system? It boils down to the dollars for hours question again. If a design leads to more than four additional hours of work in a given month, then it better be worth more than $1,000. Otherwise the company is losing money faster than it could possibly be gaining.

Considering the fact that the developers probably haven't even realized that the content they're looking for has changed, it will likely cause at least three hours' delay for even the first instance of dealing with conflicting versions of content.

In this recent project, I can't imagine how much time was spent on support of the system.

blog comments powered by Disqus