A little while ago I read an article entitled “A long winding road out of beta”. Initially after reading the article I began to wonder what happened to the logic behind a beta release. Originally, it was a period of testing that was performed before a piece of software was released to work out any final bugs. What has changed between then and now? Are users getting used to unstable software? From a personal perspective, it has been disheartening to watch the general public come to accept “rebooting” a computer as a solution to a problem. To me, that is equivalent to buying a new bedroom set because the dresser handle has a loose screw.
As frustrating as it is, this general decrease in software quality also creates opportunities. As people get used to crappy software, a company with a quality product that is competitively priced stands to win huge Market share. This winning product may (and probably will) have fewer features than its competition. As long as it does what it was intended to do reliably, consistently and correctly, people will begin to see just how bad some of the other offerings are and switch.
I then pondered on what causes such a lack of quality. The short list of answers I came up with is: Lack of pride in a product, lack of peer-review, human error and compressed timelines. The list can grow indefinitely, but those were some of the major ones that stuck out to me.
How does one combat these confounding factors? For a lack of pride in a product, one must have people who have a personal stake in their work. By this, I don’t mean giving bonus’ based on achievements, I am referring to people that work for the enjoyment of the work itself and not the pay cheque that accompanies it. Happy employees do good work. Lack of peer review can be resolved by having people work cohesively in groups. The kind of group that sits in a room together actively discussing all aspects of their daily work, not one that meets a few times a week to give status updates to each other. Human error? Automation I say. Automate those tasks which do not require thought. Computers are good at doing. People are good at thinking. Lastly, compression of timelines must be defeated in the scoping stage. Every project has a momentum life-cycle. It is built slowly at the beginning, constantly increasing until a peak is reached and then rapidly decays. If a project is properly scoped, this peak happens about ¾ of the way through, which leaves time for final tweaking and wind down before project completion.
In the end, it all comes down to that “good” feeling you get when you complete a project. If it isn’t present, odds are, the final product is really a beta.