Testing: Try again, fail again, fail beta

A habit of lab-style repeat testing and launching unfinished products is one of the key reasons why good technology firms thrive, says Ben Hammersley

Compared to the slow-motion disaster movie that is climate change, crashed sites and sub-optimal apps are problems that we can generally take in our stride – provided we've had our daily caffeine fix and aren't battling a deadline. There is no such thing as a finished digital product, and the most highly regarded applications are not those that never fail, but those that fail gracefully.

Where previously we wanted perfection from the things and services we consumed, now, as we grow used to living in a world where iterative design and Moore's Law dictate that everything is a work in progress, we are increasingly comfortable with the provisional, provided it serves its purpose. That's especially true when, in return for using a digital product at an earlier stage of its development we are asked to contribute our expertise or opinion to the work in progress.

Online everything is beta because the state of perfection is permanently receding on waves of innovation. An app that is adaptable, or that can deliver a soft landing even when it fails, is far more valuable than the perfect-for-a-moment app that lacks the flexibility to cope with whatever is coming down the line next or is late.

As we engineer more and more complex systems from vast amounts of code, we are developing our understanding that, with so many inputs, a consistently optimum outcome is simply impossible. The digital mindset is one that accepts that, in a perfect world, a new application would be perfection itself, but in reality it'll never be better than merely very good. This capacity to be very good, even in non-perfect conditions, does not happen by accident. It has been designed into the app, using the principle of failing gracefully as a guiding light.

Failing gracefully is what occurs when, for example, a website built with a brand-new coding technique is encountered by an old browser that doesn't have the necessary capabilities. No, the browser will not display all the elements of the site, but it will not react by having a hissy fit and crashing; correctly designed, it will cope to the best of its ability, because it has been designed to be flexible.

These are the apps beloved of coders everywhere; the apps that make even their failures look like successes. A clever web designer, too, will ensure that their design itself fails gracefully. Access a series of webpages made with Flash using the browser on the iPad, which has no Flash support, and you can see varying degrees of success at attempts to create designs that still work with the Flash content – pages that fail gracefully.

Failing gracefully is underpinned by a concept that comes as close to being a defining principle of internet design. The maxim "Be liberal in what you accept and conservative in what you send" was coined by Jon Postel, a legendary internet engineer, but he merely put into words what the thousands of architects of the internet put into the network, and the software that runs on it.

Postel argued that the ideal to aspire to was, for example, an email programme that could accept any email, however broken, however corrupt the code, however out of date, and work with it successfully enough to display the message. The emails it generated itself, on the other hand, should be as near to flawless as possible, and it should be working to fix any sub-standard emails received before it sent them on.

Some products and situations lend themselves better to failing gracefully than others. A flawed retail website is one thing, a glitch in a council's website for paying taxes is quite another. Where money or personal safety correlate with digital complexity, even the most exquisitely designed app may not feel trustworthy enough.

We have already seen that the financial industries have created a singularity of complexity with their software, one that is incapable of failing gracefully on a consistent basis. There are other digital products in development that, though they sound exciting, are treated with scepticism by people who know a lot about software design. Take the self-driving car, for example. Google is at the forefront of the development of an autonomous car, though numerous vehicle manufacturers are also working on the concept.

Its exponents claim that mass take-up would slash the number of deaths on the roads, once the pesky fallible humans have been removed from the equation. You wouldn't have to go far to find plenty of software engineers who would raise their eyebrows at this.

It's tempting to imagine a safer road network with fewer poor drivers, but failing gracefully is not a concept that translates easily to a car with no driver, and especially one where you've been tempted to remove the steering wheel. The same reasoning goes to explain the social, if not technical reason behind not having flying cars now that we're living in the future. A flying-car failure would be anything but graceful.

Most of us balk at the potential for disaster suggested by failing technology in such an obviously life-and-death situation, but we already live in a world where countless lives and limitless billions of dollars are dependent on the soft landings engineered by technology workers. And on a more everyday scale, we are evolving away from a natural philosophy of broken versus fixed, or in-progress versus finished.

Even 10 years ago, a new programme would go through closed beta testing in which a small group people would test a new app for flaws and bugs. These days beta tests are often open affairs involving hundreds if not thousands of volunteers. These people sign up to play a game, use a web app, or even read the first draft of a new manual on a programming language, and send their comments and criticisms back.

There might be some risks or frustrations attached to using a product that's essentially still slightly broken, but the users gain access to the latest information or entertainment, and the glow of knowing that they are participating in collaborative work on something that has value to them. And why not: after all, the very good, though it never quite catches up with perfection, keeps on getting better.

This is an edited extract from '64 Things You Need to Know Now for Then' by Ben Hammersley (Hodder & Stoughton). To buy this book at the special price of £16.50 (RRP £20) visit independentbooksdirect.co.uk