Build One to Throw Away

In Fred Brook’s classic The Mythical Man Month, he famously argues that:

In most projects, the first system built is barely usable. It may be too slow, too big, too awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. . . . Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.

Of course, Brooks later qualified this declaration, noting that—even better than building one to throw away—incremental approaches might enable multiple passes through different architectures before any single instance is actually built.

James Fitch

But what about large-scale Content Management System implementations?

Is it a forgone conclusion that any organization’s first implementation of a new CMS is doomed to be at best “barely usable”?

Is the reason so many organizations are unhappy with their CMS implementation exactly that it is this first attempt, but one which they never had the time or budget to redesign and redevelop?

Further, when the budget for a redesign or re-development does get created, isn’t it normally done on some wholly new platform, and thus the cycle repeated with new concepts and newer technology but no more success?

Learning Curve for Popular Open Source CMS Platforms

This graphic was popularized in the Drupal community when @cistov posted it to twitpic, but it actually originated in this blog post on MMORPGs applied to CMS platforms by Ukranian Drupalists Shvets Group.

It reflects, in a self-deprecating fashion, the very real experience of designers and developers alike as they take on a significant new platform, framework, or application.

It isn’t just a Drupal problem.

In fact, I’d argue that at least in open source communities like Drupal there’s substantially more opportunity to learn from the painful experiences of others.

What about organizations adopting proprietary, closed-source CMS platforms for large-scale web properties?

Their need to learn the platform (what it does well, what it does poorly, how to work within the grain of the system and where you can extend its behavior most naturally) is no less, and yet I’ve never known an organization with the budgeting prescience to build one to throw away first.

How do you go about mitigating this “every time is the first time” challenge?

You can hire consultants and implementation partners, of course, preferably who’ve done something before which closely resembles what you’re trying to do.

You can pilot / prototype / create proofs of concept – both at the user experience level (wire frames, paper prototypes, sketches, or working interfaces) and at the technical level – working technology implementations of key risk areas.

You can use scenario-based evaluations of the platforms you’re choosing between, creating realistic expectations for content administrators as to how they’ll accomplish their tasks.

What other strategies have you found successful?

About the Author

Formerly the Managing Director of Boston Connective DX office, John's passion for technology and the role of CMS are clear in his point of view.

More articles from John Eckman

Comments

One response… read them below or add one.

  1. Deane says:

    I always wonder how someone goes about becoming a partner for one of the really big CMS, like Day. I mean, how do you get that first Day project under your belt?

    I asked someone very knowledgeable in the industry once. He said, “Be prepared to lose six figures on the first project, and five figures on the second. By the third, you might be making money.”

Leave a Reply
  1. Fields marked with * are required.
  2. We will not publish your email.