
CMS Trap - hakunin
http://hakunin.com/cms-trap
======
Udo
This is basically the same phenomenon that happens with frameworks. At first,
the framework gives you a ton of functionality for the (initially) low price
of living with its abstractions. As you want more custom functionality, you
find yourself either fighting the framework with increasing levels of
desperation, or simply coding around it. I'd argue that the best frameworks
are such that you can code around them without causing huge overhead or
resorting to objectionable tricks.

The same goes for CMSes. Many CMS customers would probably be better off if
they took the CMS editor interface as a separate component and wrote the
actual page renderer as a custom development separately. The trouble is of
course, content systems make it very hard to do that. Having to make things
work with the native mechanisms (and the often horrific underlying data model)
is what makes huge CMS projects fail or at least perform miserably for
everyone involved.

On the very top of the list of abhorrently convolute CMSes would probably have
to be Typo3, followed after some distance by Drupal. But the more you work
with the initially-liberal Wordpress the more you discover it's not that far
behind either.

This reminds me of a bygone era: my startup (now long gone) had its own CMS.
Sadly, that wasn't our actual product as we were a pure service company and
the CMS was only a tool for us. In hindsight, we should have done it the other
way around. Our CMS wasn't perfect, but it shone in a few areas that made the
life of both developers and content editors very easy: a simple, accessible
data model and an easily extensible page renderer. Unlike many other solutions
it was designed to get things done, not to bill a lot of consultant hours.
I've yet to come across an open source (or commercial for that matter) CMS
that works equally well.

~~~
brazzy
The article is NOT about building systems on top of a regular CMS.

It's about starting to build a specialized system and ending up building a
generic CMS because of an urge to make everything runtime-configurable.

~~~
Udo
From the article:

" _It’s the passion that makes us lose sight of the danger looming ahead, the
trap we’re edging towards thanks to our subjective assumptions and vague
speculation, the trap of building a overdesigned and overcomplicated system
for its own sake. A CMS trap_ "

and, to address your objection:

" _When you are asked to build an app with something like Drupal, you are in a
whole different realm, where the CMS trap is pretty much your perpetual state
of being._ "

As I said I would broaden the discussion even further. Over-design and over-
complication is very much the hallmark of pretty much any CMS I have come
across. The system becomes the biggest hinderance in respect to the
realization of content and functionality. This IS pretty much what the article
is about. It deals _at length_ with unsuitable customization decisions.

------
danso
Wow. This should be a must-read for developers, especially ones working in the
content field.

I've made a few complex apps that use Google Spreadsheets as the
backend...that is, to hold the public facing data and not, obviously, any
proprietary data. This makes it very easy for those who have to maintain the
app to enter in data. The downside is, of course, the inability to strongly
enforce business rules and to denormalize things...but that forces me to
reduce the data design to a bare minimum, which is often the best strategy in
the first place.

I hope I never have to be in a situation where I'm building a CMS-type system
for a client. People who haven't dealt with data-modeling or relational-
databases don't appreciate simplicity...in the end, most people want something
that they can type a headline, some text, and attach a photo or two (i.e. a
Tumblr). But if you give them reins to design the system, they will inevitably
want you to build them something Drupal like. In my experience, I've found
that all these different content-relations end up being unused, and the client
ends up hacking around them just to get a simple post up.

------
Breefield
@rudyrigot and the team @prismicio [http://prismic.io](http://prismic.io)
really have a handle on this problem. They believe a github-esq content
management system makes the most sense for content creators, and a content API
makes most sense for engineers to distribute that content inside of a variety
of platforms (mobile, a rails app, whatever). Saw Rudy speak at Zendesk/Rails
meetup this month, it was a very good presentation (I am not affiliated with
Prismic).

I've been playing with their ruby-kit, so far so good, really liking this
approach and plan to see awesome things ahead.

~~~
icedog
The article is stating that developers should lean towards going static versus
using any content management system. Would you like to provide a meaningful
comment about how Prismic voids this author's argument?

~~~
Breefield
[edit] Apparently we may both be on the wrong page:
[https://twitter.com/hakunin/status/405874291100901376](https://twitter.com/hakunin/status/405874291100901376)

Prismic allows you to "go static" for very little dev cost. Your content
creators get a nice editor and can publish their content as needed,
effectively making it static for you (the dev), as though it went through a
build script (Jekyll or something "static"). The CMS gets out of your way, and
you get to concentrate on making your app work, not getting into the
complexities of building/maintaining a custom CMS.

I mean, that's what the assertion that static is the way to go eludes to,
unless I am incorrect about the entire point of the article. It's about not
getting dragged into the bog of making a CMS.

The author outlines various scenarios: do it yourself, to building your
complex app on a CMS (ugh), or just going back to static because it is the
simplest, hardest to fuck up option. I don't think he explored the idea of
content management as a service fully, which is why I brought up Prismic—it is
another option, and in my opinion, a very good one.

~~~
hakunin
I should've made it clearer, sorry. When referring to CMS in the article, I
refer to the wider meaning of a content management system, the code that you
write as a developer of your own site, which happens to manage your content.
Not a CMS that one could download and install.

~~~
sdoering
Funny thing. I understood your analogy just great. I just remembered all the
situations, where we as a company were/are trapped with the CMS we've got.

So it worked for me as a editor gone code-writer as well as a editor gone
conceptual project-lead.

------
foz
From an architecture point of view, I'm convinced that the CMS is better
treated as a service, and not as part of your web application. This is
especially true in a larger organization where content needs to be collected
and managed in different ways (via import, or where people edit or curate
content).

At the start of this year, the company I work at had about six different CMS
platforms. Many of the applications that used them were built on top of CMSs,
and were tightly coupled to them. As for static content generators, we tried
that. It really didn't scale, especially for dynamic content. Too many hacks,
deploys, and hard to train people.

As of today, our team has switched nearly all public content for our company
to LocomotiveCMS
([http://www.locomotivecms.com/](http://www.locomotivecms.com/)), and deployed
a centralized multi-tenant system. In many cases, we use our Locomotive
instances as an API, pushing content via the API or the command-line tool,
wagon. The CMS then renders HTML templates (or even JSON), which are consumed
by our applications via HTTP. Sometimes it's just a tiny part of a page, or
sometimes entire mini-sites. As a result, most of our apps don't need to know
about a database.

Whenever there's a change that requires a new model, or the addition of a
field, it can be done quickly through the LCMS back-office UI (or the wagon
CLI tool). We update the application(s) affected, and re-deploy. Non-techies
can edit the content using the admin web UI in a familiar way.

In any case, it's been working really well for us. The CMS has become an API,
a service, and a separate app, shared by many applications. We've become more
flexible and efficient as a result, our web applications are no longer
burdened by CMS frameworks or admin interfaces of their own. And we dont have
to struggle with Sharepoint or Wordpress or any other nonsense.

It's been a fundamental shift in how we think about the CMS, and has scaled
well across multiple projects.

~~~
Kiro
So you need to re-deploy for a simple typo fix?

~~~
did
hey @kiro, I'm Didier, creator of LocomotiveCMS (www.locomotivecms.com). You
do not need to re-deploy for a simple typo because the structure of your site
and the content are definitely separated. You or your content editor will use
the user back-office to fix that typo.

However, if you want to change the layout or tweak the style, you have to use
Wagon and its frontend tools (SASS, Compass, Less, Compass), make your
changes, test them locally with the embedded web server in Wagon, commit them
to git if you version your site structure and then deploy. The redeployment
won't touch the live data unless you modified your data structure. Hope my
answer was clear :-)

~~~
Kiro
Thanks for the answer! I will give Locomotive a try next time I need to
install a new CMS.

------
vinceguidry
I wrote an app for my company to extract data from the database and form xml
feeds for various e-commerce services. I took the opportunity to learn OO
principles and read through Object Oriented Design in Ruby.

What I eventually came up with was pretty much exactly what this post is
advocating for. YAGNI was the rule, I was new and wanted to demonstrate
results quickly. Instead of classes, I put constants in modules, realizing
that all that a class I'd written was holding was basically a hash, and since
that data wasn't changing anytime soon, they might as well go in a constant.

I caught the refactoring bug sometime around when I was tasked with adding a
third service. I found turning the logic I'd created into proper classes
incredibly easy, make changes, run rspec, rinse, repeat. The interfaces
between the various pieces were surprisingly loose. So I could play around
with different implementations of a piece of logic and at every point have
something that could be made to work if I suddenly had to shift gears.

I had two services and they were each slightly different. Waiting to build the
abstractions until I had multiple implementations of them wound up being a big
win. Now that I have a third, I can already tell that it's going to be an easy
add. I spend much more time figuring out service-specific stuff than wrangling
with my code.

Hard-coding really does get a bad rap. You're not building a castle, you're
fixing a pressing business need. If you do it well, then one day you'll be
able to open-source your work, because your company will want to add more and
more to it because of how badass it is. Not because your delusions of grandeur
led you to over-abstract everything to the point of uselessness.

------
bct
Back in the old days (2005) we used to call this Do the Simplest Thing That
Could Possibly Work.

~~~
jsdalton
Or another way of looking at it: "You Ain't Gonna Need It"
([http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it](http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it))

------
maxk42
I am SO sick of spending more time configuring the CMS than writing code.

Oftentimes, I could've built a product from scratch in the time it takes me to
Google the undocumented quirks of some stupid YAML file.

~~~
ams6110
But the piece was not about using CMSs where code would be more appropriate.
It was about turning your bespoke application into something _like_ a CMS by
architecting for maximum flexibility and configurability everywhere, building
complex "admin" interfaces, and implementing data-driven runtime behavior
before any of that is really necessary.

You can do all of these things with 100% test coverage, but that doesn't
relieve you from dealing with the weight of the architecture and extra work
when you try to add or change functionality later.

------
Domenic_S
Just because you use a CMS doesn't mean you have to use it for everything. If
you're managing content (blog content?) use a CMS. If you're making PPC pages,
host them statically somewhere. If you sell something, use ecommerce software
for that part.

The right tool for the right job.

~~~
patio11
_If you 're making PPC pages, host them statically somewhere._

I'd counter recommend this. In my limited experience with it, dynamic PPC
landing pages are so effective as to be almost cheating.

BCC's AdWords campaigns are not doing well in 2013 for what I believe are
unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make
URL #1 and URL #2 roughly the same today but will automatically switch URL #1
to a different creative in a few days have been worth, guesstimating a number
here, somewhere north of $20,000. (Bingo cards are a very seasonal market. For
the last couple of weeks, most teachers have been in the market for
Thanksgiving bingo cards. This will not be true in a few days. The #1 URL,
which I use for many of my campaigns, uses some really dead simple heuristics
to guess which creative to show people. The heuristic was worth > 10% lift in
conversions versus alternatives like "Pick our most popular activity ever",
"Pick an activity at random", and "Pick Patrick's guess at what would convert
best."

[http://www.bingocardcreator.com/lp/try_online](http://www.bingocardcreator.com/lp/try_online)

[http://www.bingocardcreator.com/lpc/thanksgiving](http://www.bingocardcreator.com/lpc/thanksgiving)
<\-- There are actually about ~900 landing pages like this, which is a trick
that few people manage if they do them in static HTML.

~~~
Pitarou
Can I check I've understood you right, Patrick?

You have some code that infers from usage that, for instance, civil rights
cards are popular in late January (Martin Luther King Day is on January 20th)?
Neat! :-)

~~~
patio11
Right idea, but I'm not sure it would work for your example. MLK Day for the
longest time didn't work correctly. I had a string tied around my finger about
that bug for 3 years, can't remember if I squashed it in January or not.

------
na85
>A CMS Trap is a state of a web-application in which the development of
content management systems is obstructing the development of the content.

I think this pretty neatly summarizes my experience working with Drupal.

------
SolarUpNote
I think the key question is: At what point is building a user interface more
expensive than hiring a full time developer?

~~~
dreamfactory
or buying a product

------
kenster07
Love of complexity is a programming disease.

~~~
AsymetricCom
Complexity can signify a complex problem on a simple domain, or a simple
problem in a complex domain. You simplify one place, you're just pushing the
complexity somewhere else.

~~~
jacques_chester
I optimistically called this Chester's First Law of Complexity:

    
    
       Essential complexity in the problem domain is a conserved quantity.
    

The idea being that someone, somewhere, always has to pay the piper for any
given architecture. It might be paid at write time, or at read time. By the
server or by the client. By the programmer or the sysadmin. By the compiler
guy or the programmer. By the code that defines the data structure or the code
that relies on the data structure. But _somebody always pays the toll_.

Then I found out that Larry Wall had beaten me to it with the pithier much
pithier "Waterbed Theory". Kolmogorov partly so with the somewhat less pithy
Kolmogorov Complexity.

------
paulftw
Overengineered software systems are like sex - every generation thinks they
invented it.

------
nevvvermind
Oh, c'mon. I was currently doing the exact same thing the blog post advices
against.

I was designing, centralizing, decoupling. Then some changes came about. I
implemented them, then watched them fluently rippling throughout the system.
"How cool is that?".

It was some time ago when I was an OOP-design junkie (I think it's analogous
to puberty: exaggerating). I think I passed that, as I frequently wonder if
I'm over-designing and get back to using plain strings, constants etc.

I once read that, designing a plugin (be it a pattern or an actual plugin),
try no less than 3 different implementations.

He's right, though. I work with Magento. Try adding a new backend form in that
beast.

------
fiatjaf
Ok. Here's an idea:

Imagine a code editor (probably embedded in some online where the developers
would also work/code) that would show all the application code.

For developers, everything would be editable, so they could change logic, add
logic, database calls, anything. On the other hand, for content editors, only
strings (and arrays and numbers) would be editable. So the whole page would be
freezed except for the parts between quotes. The developer could then hard-
code these possibly-editable-values at code time (or leave them blank) and the
non-developers edit them: categories, text content, values.

~~~
fiatjaf
Hmm, there's those cases in which, to make use of database data, the code has
to run into loops, checking and getting data from fields in which it was
stored. This can be a problem, as developers using this metodology I'm
describing would have to organize their code to handle static values just as
if the values were being fetched from a database, but this problem must have a
solution. I'll think about it.

------
prottmann
You're talking out of my soul! I see this behavior many many times in the last
10 Years, i admit, i do the same long time ago ;-)

The problem for the mass of developers is, that they "fall in love" with their
CMS and that make them blind for obvious things.

We shift away from CMS as central point for web and web-application. CMS is
only a tool to maintain simple static data in various languages for many
people. For everything else (like shops) we use other systems, that are NOT a
integrated part of a CMS.

If interaction between CMS and ohter systems is needed, implement a separate
and clean API.

------
lifeisstillgood
I am going to look so silly :

\- all content served as json through a REST interface

\- all content created in best way possible and reduced to either static json
or Dbase backed templates

\- content has metadata to keep it indexed

------
ThinkBeat
If there is a reasonable need for content editors to be able to update content
in web site allowing them to do so in a quick and easy manner is a good idea.

Seeing this as easy, and building a custom application to handle it, will
quickly become a bad idea, and an artifact of "not build by me, I can build
better" mentality.

Being able to leverage a tool that is both proven and easily available to
solve this problem makes sense.

Expecting the cms to solve every problem and be the only tool used is also a
big problem.

As to whether to provide the users with a means to define new pricing models
and change current models, depends on how frequently it needs to get done, how
much dev resources are needed to keep up with demand, and what the release
process is like.

If you are in an enterprisy place. First an issue must be created to update
the pricing model or create a new one. This probably goes under change
control, and it will be addressed in the next meeting of the governance
committee.

If all is approved there it will be passed on to the project manager who will
create a backlog item for it.

Then once the current sprint is completed, a new prioritized list of tasks are
distributed and in the best scenario the issue is handed off to a developer
with a high priority.

The developer will analyze what changes are needed, design the new pricing
model, implement it, create and run unit tests, ensure it goes through CI.
Then he will write the test cases for the new functionality and move on to the
next issue in the back loc.

In 2-4 weeks when the sprint is over the worst case is that the dev branch is
promoted and the test team is assigned an issue to test and regression test
everything.

Once their sprint is done, it will be promoted to Staging and more tests and
sign offs and then after a month or two the new pricing model will hit the
shelfs and the executive who requested it might already have forgotten why it
was an issue to begin with, or the client he created it for has long gone with
a different company

All of that to say sometimes it makes very good sense to create a decent way
for the end users to be allowed to modify and create new pricing models.

Just like its easier to allow the end users to edit the content of web pages.

It would in my opinion be absurd to create an ecommerce system where the
pricing and products require code to be updated. Much better to leverage an
existing product or worse case write the logic to allow the users to make
changes on their own.

~~~
hakunin
I agree, what you are describing sounds like what I pointed out about bigger
companies in the article. They not only can afford this, but they pursue this
intentionally.

> It would in my opinion be absurd to create an ecommerce system where the
> pricing and products require code to be updated. Much better to leverage an
> existing product or worse case write the logic to allow the users to make
> changes on their own.

This I disagree with. An e-commerce system that deals with limited number of
products (like a printing shop) could easily start with hardcoded base prices,
it will be months of growth and rare pricing tweaks in code before this starts
becoming an issue (based on my own experience).

------
mavhc
ie. Don't write a programming language when you're supposed to be writing an
application.

