10-Minute Software

The other day, I was reading the Wikipedia page on McMansions (via Kottke). It was extremely interesting, and it made a good point:

The movement of the “atrium concept” home layout from popularity to ubiquity in modern American architecture stems largely from the “Ten Minute House” theory […]

Most realtors agree that a client will like or dislike a house within ten minutes of entering. Combining a home’s foyer with a two-story ‘great-room’ leaves secondary rooms more visible, making it easier for agents to show the house – and hopefully win the client over – in ten minutes or less.

So a 10-minute house is a house that only has to look good for about ten minutes. You might find out that the house sucks in the weeks after you move in, but that doesn’t matter because it looked great for the ten minutes it took to sell you.

This theory needs to be expanded to encompass software as well. I maintain there’s a lot of “10-Minute Software” out there, which is defined as software that really only has to work well in the 10-minute demo. When you get it purchased and start trying to work with it, you find that it actually sucks, but it looked great in the demo.

This is usually software that skimps on architecture for the sake of functionality. It’s software that focuses on superficial widgets that play really well in a 10-minute demo, but that very, very few people actually use. Meanwhile, the underlying architecture of the system is crap.

I wrote about this a few months ago:

As a developer with the capability to write code, I find myself much more concerned with architectural matters. Functionality can be programmed, but I’m at the mercy of architecture. Put another way, give me the right tools and materials, and I can build anything. But give me nothing but a pile of sand and a toothbrush, and I’m pretty much screwed.

Ian Muir wrote about this same thing a few months back:

In my experience, most companies are heavily sales driven rather than product driven. The company superstars are the sales team and development/engineering works silently in the background. […]

Essentially it comes down to one idea. Making a better product will likely increase sales, but increasing sales doesn’t create a better product.

And that’s really the truth of it. There’s a lot of software out there that’s really a “Sales Presentation in a Box,” masquerading as a content management system or a groupware platform or something else. New functionality is approved on the basis of how well it will play in a sales demo rather than how much people will actually use it to do something useful.

The problem is that architecture isn’t sexy to the people making the purchasing decisions. But the underlying architecture of a piece of software – especially something like content management – will make or break it. Widgets and interface cruft may look snazzy, but if you’re painting the porch while the foundation of your house is crumbling, you’ve got a problem.

So what’s the solution? Extended demos and proofs-of-concept. Don’t just watch the demo and perhaps play with it a bit. Instead, try to implement a piece of your plan from soup to nuts – from content creation to content publishing. If it doesn’t work and the company doesn’t have answers, understand that paying for it isn’t going to make that problem going away. I can easily count a half dozen pieces of software that I wouldn’t have purchased if I had invested more time in an evaluation.

(Be careful too that you don’t “extrapolate a theory.” I’ve done this before: you get about 35% into implementing your proof-of-concept, and then you think, “Well, I’m far enough, and I’ve read about how to do the rest, so I’m sure it would be able to handle this.” You’ve just made some assumptions that may or may not pan out – often the latter. Do yourself a favor and implement a small, representative piece of your plan all the way.)

An example that I read somewhere else, but can’t remember where –

Workflow in content management comes in vastly different levels of flexibility and complexity. During a sales demo, you’re probably just going to see someone submit some fake content, then login as another user and approve it. That’s great, right? Plays well in the demo – people love it!

But how is it actually done? In Ektron or eZ publish, you can configure it right in the Web interface. For Documentum, you have to spend five figures more for a Visio-like “workflow designer” which generates XML which you have to install in the server, etc. Same sales demo; vastly different levels of love in the long run.

And it’s really all about the long run. I’m still looking for “Ten Year Software.”