Just found this article on the IBM Website by Amy Wohl, and I must say it’s quite an interesting read to say the least.

When is Software Ready for Users?

Once upon a time, developers worked on software in the privacy of their offices, writing and testing it until it was finished. Only then would they ship it to users.

Today, things are very different. Aggressive users can see code even in a pre-alpha state and large numbers of users are invited to join in what amounts to a high volume test in the code’s beta period.

Some software vendors have earned a reputation for letting the users be a significant part of the testing process, looking for bugs as well as for problems with useability or missing features. In fact, many users have given up buying software (or even upgrades) on their first release, waiting for a subsequent release or service pack before they feel confident enough to try a software packaging, however appealing it might be.

But some software users revel in being able to use software as soon as possible. They enjoy every bug and bug report, feeling that they are part of the software’s development process, rather than just a user.

Keep the Pioneers Separate from the Users

The trouble is, keeping the pioneers, who like to catch your arrows and tell you about them, separate from the users who would just as soon only see a software product that is complete, finished, and very likely to need little or no assistance from the technical support staff. Here are some helpful hints:

(1) Ask. Users often know whether they would like to participate in the development process or whether they’d like to spend their time on their primary work tasks. Let them know what they’re getting into if they try software at various stages of the pre-gold code process.

(2) Tell. Tell users just what to expect from a pre-alpha, alpha, or beta copy of your software. Tell them what will happen to their work if a fatal bug occurs. Tell them how much support you can offer them and how that support works (email? FAQ? telephone hot line?) Honesty is the best policy here.

(3) Only offer very small rewards for participating in the development process. We note that some vendors offer BIG rewards to beta testers, leading some folks who are really unprepared for the work to take it on. Better to keep the rewards smaller to reduce temptation and to do a better job of non-disclosing just how much work you expect.

Be Truthful

I really respect a developer who tells the truth. Recently, I’ve been angling for a copy of a particular piece of Open Source software that’s not quite at alpha. It’s actually available on the web and its owners have told me where it is and that, of course, I’m welcome to download it if I want to. They’ve also pointed out that for someone like me who is (a) not a programmer and (b) mainly wants to see how the product looks and works, but not to help debug it, it would probably be better to wait a while.

They’ve figured out (correctly) that I’ll have a better first impression if their baby product doesn’t crash the first time I try to use it. If only every developer was as thoughtful.