Back in 1998 when I started teaching myself web design, I would spend a lot of time talking to clients and trying to explain what the web is, and why they needed a web site. Most of them didn’t grok it, and disappeared back into their analogue world. The internet wasn’t all that new, but it was new to them.
The design cycle was pretty long. There’d be meetings where I’d try to figure out what they wanted. Then I’d go away and put together the site architecture – which pages link to which and what do they have on them? I tended to work very hierarchically, starting with a home page at the top and then creating a sort of family tree of pages. I’d do draft designs at the same time – screens, rather than wireframes, because most of my clients weren’t sophisticated enough to know what a wireframe was. (Come to that, neither was I.)
Then we’d haggle. They’d tell me I was charging too much, so I’d pare down the scope of the project and give them a cheaper price. Eventually – hopefully – we’d have a deal. I’d then go away and design the site, frequently also editing or writing the content, and Photoshopping the images.
Then I’d upload the site to their hosting, they’d pay me (or I’d sue their asses), and that would be that. Job done.
Some projects took months, half a year or more. How quaint all that seems now.
That was eight years ago, but I am still having the same conversations now. All you’d have to do is replace ‘internet’ with ‘web 2.0’ or ‘blog’ and you could parrot one of my client meetings from ’98 almost verbatim and no one would notice.
The problem is, companies are still have very long decision making cycles. These painfully slow processes are fine when the world around you moves slowly, but technology changes quickly. If you want to get the best out of social software and ‘web 2.0’, you have to be on top of what’s going on. That doesn’t mean jump on every bandwagon that goes past, but it does mean assessing and adopting new tools at a speed a bit faster than glacial.
IT departments are used to the traditional software development model – one, two or more years before releases, and what you get is what you’re stuck with until the next update, bugs or no.
Web software doesn’t work like that. The adage ‘release early, release often’ has been taken to heart by many of the developers working on social software and web apps. Start with a limited alpha, move on to an invitation-only beta, scale your beta slowly and then, eventually, you might reach the mythical Version 1.0. Or not, depending.
For users of this kind of software, the update is a regular attraction. Some software even updates on a nightly basis, with test builds released for the keen user to try in between major releases. And you do have to keep up, not just for the bug fixes, but for the new features which are quietly released, with no fanfare and, usually, no additional fee. Major upgrades you might have to pay for, but in the most part, these small apps accrete features as a matter of course.
Within big business, this poses a problem. If you have a traditional IT department that likes to slowly do its due diligence, it’s going to find that the software it assessed a few months ago is unrecognisable today. It’s tempting to say that this is irrelevant – businesses use enterprise software so why should they care that the small developer releases early and often?
Well, if you want a decent RSS aggregator, or a desktop blogging application, or even just a blogging platform, you’ll be hard pushed to find anything half decent from a major player. All the good ones are created by companies (or individuals, or open source communities) orders of magnitude smaller than your normal enterprise mush.
Why does this matter? Well, whilst your IT department is faffing around on a never-ending cycle of due diligence, you’re failing to take advantage of the really useful stuff that’s out there. The opportunities to use blogs and RSS and wikis to help your staff do their jobs more easily and more efficiently are passing you by.
So I’d like to propose a new adage for those struggling with the concept that software doesn’t have to be perfect to be useful: Adopt early, adopt often.