Relative Sanity » blogging

How not to build an in-house CMS

relativesanity — Mon, 17 Nov 2008 13:32:02 +0000

It’s so easy to create a content managed website these days that it’s often equally easy to be paralysed by choice. This journal runs on WordPress, and uses a modified version of a theme by MidMo Web Design. It took all of 20 minutes from download to test-posting into this theme.

Picking the engine itself, though, has taken about 2 years, and was based on one thing: immediacy.

Choices, choices

Choice is good, right? Competition is even better. I’ve recently become jaded with my own erstwhile approach to site management systems. That approach could be boiled down to two simple statements:

Content Management Systems are simple
Given enough projects, I can incrementally build my own while getting paid for it

The implication being that “my own” will be inherently better than any of the off-the-shelf systems that are already out there, because I’ll understand it from the ground up.

What really happens can be summed up by these parallel statements:

CMS is as “simple” as word processing: easy to describe, easy to prototype, hard to perfect
Clients are not software designers, and I’m a scorched-earth perfectionist

All of which results in me, having idealised the first two statements, but followed the second two, writing this post two years later.

Build it in increments -> (step 2) -> profit!

If you are planning on building an in-house CMS, I’m assuming that you’ve already come up with all the rationalising arguments about why it will be “better” than off-the-shelf. It doesn’t matter whether you’ve convinced yourself that the client’s requirements are beyond the scope of any existing system, or whether you’re just full of “Not Invented Here” Kool-aid, the point is that you and your team are committed to delivering a CMS to fulfil your client’s spec.

Of course, what I’ve just described is a bespoke CMS for a single client. Everyone knows that’s not scalable to larger projects, so how do we get around that?

All together now:

We write the core of the CMS for this client, and build it modularly so that we can just give them what they asked for, but reuse the core on the next project!

Bingo. Sounds great, doesn’t it? You make a bit of a time loss on this project, but it’s an investment, because next time around you’ll be mainly writing modules for the next client’s functionality. If the next client has the same spec as this client, it’s instant profit! What can go wrong?

This is where reality creeps in. You build your CMS nice and modularly for the first two weeks. You then realise that you’re not quite finished the core yet, and you’ve only got two weeks left to implement the various bits of functionality as modules. You panic. You know what modules you need, so you start building the remainder of the core with those modules in mind. You maybe even start building some modules into the core, promising to refactor them out on the next project, because you finally remembered your Pragmatic Programmer, and suddenly it’s all about “just get it working”.

You complete the project on time, and what do you have? A half-bespoke, half-modular monster that is going to require a serious refactoring job to make usable for the next project.

However, you’ve learned a lot. This is a key realisation, and often missed. You’ve learned a hell of a lot, and this is where the rot starts. You’ve learned so much that you convince yourself that, on the next project, it would be insanity to try to reuse any of what you’ve just coded. What you decide to do instead is to reuse the knowledge. Oh yeah, baby – we salvaged something after all!

So you start coding again from scratch. This time it will be better, you say, since you know how it all went wrong last time, and you’ve come up with five great new ways of modularising from the get-go. Then client number 2 rolls along.

One of these kids is kinda different

So with your newfound “I get it now!” knowledge, you start implementing The Plan again. Client 1 was a false start – client 2 is the real deal. Now you know how to make it modular, you’ll do it right this time.

Except the same thing happens. This time, because you’re having so much fun coding, and because you’ve convinced yourself that last time you caved and started coupling the core to the modules too early, you hold out to week three to produce the core CMS. But again, week three rolls around and you’re still not done. With only one week left to implement the functionality that took you two weeks last time, you start panicking and even more coupling happens. Worse, your project runs over time and is late.

So far, with two projects in the bag, you’ve overserviced both, pissed off one of the clients by being late, given each a rushed bespoke system (with all the attendant maintenance overheads), and have precisely zero reusable code. Not exactly the outcome you’d hoped for.

So what went wrong?

Addiction is curable

What went wrong is that you failed to notice that your stated goals were not really your goals. Worse, you actually got what you wanted all along.

Huh?

Your implicit goal in building an in-house CMS was to reduce the amount of work you do. You’ve noticed that servicing your clients is boring, because you’re constantly writing the same stuff. To fix that, you decide to consciously write that stuff in a way that you can reuse next time.

The logical next step of that is to write an entire system that you can reuse next time. This is where the logic breaks down, because there already are systems that you can reuse. Right now. You can download MODx right now and be at precisely the point you say you want to be at in four weeks.

So why didn’t you? You didn’t because your goal isn’t to reduce the amount of work you do, it’s to increase it. What you secretly want to do is build a bespoke CMS for every one of your clients. You hope that maybe, one day, you might hit upon a pattern that you can reuse, but you don’t really care about that. You love coding, you love tweaking and refining and burning it down and starting again. You love it, and you got it.

Step zero is realising you’re addicted

So what are you addicted to? Coding? No – you’re addicted to the knowledge you’re learning, to the experience, to “figuring it out”. That’s why it’s so difficult to locate the source of the problem. When I said “you wanted to increase your workload”, you balked, because to you the work is becoming more and more painful.

The knowledge isn’t, though. You’re putting up with the pain for the rush of having refined your perfect plan for next time.

And the truth is that your CMS prototypes are getting better all the time. After 5 or 6 more clients, you might have a really solid platform.

Too bad for your first half-dozen alpha and beta testing clients, though.

Where’s the exit?

So how do you break this cycle? You decide which of these is more important to you right now. Do you want to:

Build a CMS; or
Streamline your client servicing?

You don’t get both, not right now. If you want to build an in-house CMS, you’re going to have to commit 6 to 9 months of development time to it, and the client has to be your company, not some real-world project you’re using to guinea-pig your sketches on. You need to take yourself (and perhaps another developer) off paid work and become software developers, with the attendant investment and payoff cycles that don’t exist in direct-to-client sales.

That’s the price. Once you have your CMS, you can start flogging it to people. At that point you can start to “Streamline your client servicing”.

Of course, by then, I’ll be in your sector, stealin’ your clients, because I chose to “Streamline my client servicing” straight up using WordPress and Expression Engine, with MODx in there for the really tricky stuff, and have been having a whale of a time developing modules, plugins and extras for those mature platforms you’re only starting to catch up with.

Your CMS had better do something unique.

Providing multiple feeds

relativesanity — Tue, 11 Nov 2008 12:18:15 +0000

Like everyone else these days, I have multiple feeds that encompass my online life. My main site, relativesanity.com, serves as a home page for all these feeds, so that friends and family have a single place to visit if the want to see what I’m up to. But we live in the age of Google Reader and NetNewsWire. Who wants to visit a site any more?

Certainly not me, and certainly not my visitors.

Offering sensible choices

Let’s look at all the places I live:

Each of these services provides a simple feed of content (though for some reason, last.fm has stopped scrobbling for about a week now. Grumble. Any ideas? Solved: it seems that the Mac OS X last.fm client doesn’t report password problems. It just fails silently and looks like you’ve logged in. Nasty bug.). If a visitor just wants to follow me on flickr, they can click on the flickr link on relativesanity.com and then add that feed to whatever reader they use. Job done, right?

Well, not really. I’m aggregating content on relativesanity.com, so wouldn’t it make sense to aggregate feeds? By default, relativesanity.com’s feed link tag used to be a direct pull of my twitter feed, so someone subscribing to the autodetected feed on relativesanity.com would get my twitter updates.

That was fine, but I got more and more requests to provide direct links to the rss feeds from my other accounts. Family, for example, had no idea how to subscribe to flickr (or even that it was an option.

So what to do?

Relationships for relatives

Let’s do some anatomy. link is made up of a few elements:

rel: this specifies the relationship of the link to the page, e.g. “stylesheet” or “alternate”
type: this is the MIME type of the file. For feeds, it’s often “application/rss+xml” or “application/atom+xml”
title: this is the optional title of the link. For multiple feeds, these titles may be displayed by your browser when you try to subscribe to the feed.
href: this is the actual address of the feed itself.

I mentioned “multiple feeds” there. You can, it may surprise you to hear, have multiple feeds for any given page. Most people seem to see this as a means to add different formats of feed to their page. Flickr is a great example:

I say “great” here, but what I mean is “terrible”. What are my options here? “Atom” or “RSS”? I know they’re different formats, but why do I care which one to pick? I don’t know of any feed readers these days that only handle one or the other, so as a visitor, what differentiator is there for me to choose between these? Do they provide the same content? If so, is one more “efficient” at delivering that content than the other? Will one become obsolete soon? Do I lock myself into something by choosing one over the other?

It’s a minefield, and that’s all from the point of view of someone who understands what Atom and RSS are. How’s my Mum going to feel about this, other than stupid?

Let’s look at some code:

This is how flickr codes up its photostream feeds. To my mind, it’s completely pointless. If the feeds offer different content, telling me the format doesn’t tell me what the difference is. If the feeds don’t offer different content, why offer two?

Here’s how relativesanity.com’s feeds now look:

Isn’t that neat? Some code:

Now, when visitors arrive, they can choose what to subscribe to, and the differences between each choice are clearly marked.

One feed to rule them all (sorry)

Even better, there’s an “everything” feed that aggregates all the others. This is built using friendfeed.com, which has been on my radar for ages, but for all the wrong reasons. My impression was that friendfeed primarily aggregated feeds of your friends. What I wanted was to aggregate all my feeds (and here’s the key bit) into a single RSS feed. Friendfeed not only lets you do this, it actually provides it as a first-class feature (they should have called it “myfeed”, but myfeed.com is gone).

So there we have it. Nice semantic feeds of content, all in one place, and the “everything” feed can be updated whenever I sign up to some other life-sucking service that lets me tell the world what I’m doing.

No, I’m not on facebook.