Many years ago, when I was working at Burroughs Corporation, we were building software for mainframes with dumb terminals. And then, as now, we would get regular complaints from “users” about the system being “slow”. [An aside: An old friend, David Taylor, recently reminded me at a conference that the term “user” now seems reserved for only two types of people, drug addicts and those who interact with computers. Does anyone know when and where the word user was first used to describe someone who “used” a computer? Or even why?]
When we investigated what the “slow” complaint was about, we found out that it was to do with response times between the sending of particular requests and the receipt of the next screen’s worth of data. So we looked at everything we could do to speed the process up. And there was very little we could do. And it was not enough.
We decided to experiment, and changed one little thing. We stopped buffering up the data for a screen’s worth, and started “painting” the screen straightaway. This way it actually took longer for the full screen’s worth to appear, but the user saw things happening “faster”. And perception ruled.
I think something similar is happening now with software. For many years people have been preaching the value of fast iteration in software development, and for many years the response has been to pooh-pooh the process. If it isn’t Waterfall and Cascade and GANTT Charted and Ten Years Late and Three Times The Budget and with Teams the Size of China it couldn’t possibly be a Real Project delivering Real Systems. There’s no space for Quiche in Programming. Perception ruled.
Now, thanks to people like Google, it’s suddenly OK to ship software with the word Beta attached to it and give it to people to use. Generation M probably haven’t seen ANY software that isn’t called Beta. They probably think it’s a buzzword for Web 2.0 (Yes I know I promised not to use that term, but nothing else will do in this case. Rules are proven by exceptions.)
We have to take this opportunity while we can. Organisation and industry DNA are already bringing immune systems to full alert, and it is only a matter of time before some great and good consultants decree that “using Beta software is a source of great security risk and global warming and anti-take-your pick”. Or much worse, they state that it is “not good practice”.
They couldn’t be more wrong. Practice it is, practice we desperately need, and for good reasons.
Software projects may fail for a zillion reasons. I won’t even bother to point you at the literature, there’s probably a Wikipedia article on Software Project Failure. Or there should be.
I believe that the single biggest reason for software project failure is mismanagement of expectations. Sometimes it’s because nobody knows the requirements well enough, so there are no expectations to mismanage. By the time there are expectations, it’s too late. Sometimes it’s because communications are poor, so expectations aren’t correctly set. Sometimes it’s because the expectation is flawed at the outset, in terms of time or cost or functionality. Sometimes it’s because feedback loops have been cut (a traditional blame-culture shoot-the-messenger environment where it is not done to talk about the impact of change). Sometimes it is just bad expectation management pure and simple.
Now we have a chance. A chance to legitimise the word Beta as part of enterprise software development. Deliver early, deliver quickly, make the fundamentals work, and allow the consumer to prioritise changes and new requirements more actively. And don’t call it fast iteration. Don’t call it agile development. Don’t call it doing the right thing.
Just call it Beta. Make as little fuss about it as you possibly can, but get it in the consumer’s hands.
By the way this is nothing new in organisations, it’s just that IT people haven’t been playing this game well. We are surrounded by draft agendas, draft organisation charts, draft presentations, draft proposals, draft contracts, draft minutes, draft accounts, draft policies, draft everything, even beer. And have you noticed that everyone thinks the work is done when the draft is issued? In fact I’m not sure all drafts go to heaven. But the customer is satisfied.
And remember, blogging is provisional. Always provisional :-)
yes, fully agree, involve the client (you say user), as management of expectations is key to any development. When you are transparent, you can keep the expectations low or realistic, and the whole process economical.
What works so well in world at at large might not work well at the enterprise level. In the world at large, passionate users spend their spare time/effort to “prioritise changes” beyond the working fundamentals. In the enterprise, this is to be linked with the incentives to make it really work.
IMO, in many organizations this beta evolution will reduce to yet another tool for office politics. Incentive linking will only accelerate the process.