The concept of perpetual beta is attributed to modern web applications, but I first encountered the practice–and the phrase–in the early 1990s. Yes, the early 90s, when software shipped on floppy discs! At the time, I was working at Logic Works managing a product called BPwin, a business process modeling tool built on a shoestring budget, but which, against all expectations, captured a nice little niche and turned a nifty profit. The team was miniscule, I had one developer, and a part-time tech writer and another part-time QA person. But the developer–Robert Saunders–could crank out code like nobody’s business, and liked to work overnight. I would often have a new version ready for testing in the morning, and so there was a lot of testing and retesting, constantly looking, constantly testing, wash, rinse, repeat. Sometimes the documentation would come first, and Bob would build to the documentation, sometimes we’d talk about a feature and the code would come first, but the product was almost always 3 days from ready–that is, if we needed to ship a new build, we could generally do so on 3 days notice. Bob coined the term perpetual beta, to describe our arrangement. BPwin was often sold to corporations on the promise of some new feature, which we’d rapidly build in. Looking back, we employed a lot of what today would be called lean development practices, and I never wanted to build software the old fashioned way again. Features followed the money, were delivered quickly and followed by rapid feedback cycles with the target customer to close any gaps between what we delivered and what they needed (which they couldn’t articulate until they had something to try).
So there you have it. Robert Saunders–the real father of perpetual beta.