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
Thursday 05 July 2012
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
Life & Style blogs
Watching TV after work makes you feel 'guilty and like a failure'
The 10 Best Scotch Whiskies
NHS medics are being lured away to Australia by more money, status and sunshine, survey suggests
Mac OS X Yosemite download: How to get the open beta of Apple's latest operating system
Have sex with your iPad thanks to the new sex toy no-one asked for
The 'scroungers’ fight back: The welfare claimants battling to alter stereotypes
Arizona execution lasts two hours as killer Joseph Wood left 'snorting and gasping' for air
Malaysia Airlines MH17 crash: Ukrainian military jet was flying close to passenger plane before it was shot down, says Russian officer
Malaysia Airlines MH17 crash: Massive rise in sale of British arms to Russia
Malaysia Airlines MH17 crash: victims’ bodies bundled in black bags and loaded onto trains
John Barrowman praised for Commonwealth Games opening ceremony gay kiss
- 1 Is Gideon Levy the most hated man in Israel or just the most heroic?
- 2 Students offered grants if they tweet pro-Israeli propaganda
- 3 Satellite full of sexually experimental geckos adrift in space, Russia loses control of mission
iJobs Gadgets & Tech
£65000 - £75000 per annum + Benefits: Progressive Recruitment: The client is a...
£40000 - £45000 per annum: Ashdown Group: A well-established software house ba...
£400 - £401 per annum + competitive: Progressive Recruitment: SSIS Administrat...
£25000 - £30000 per annum + competitive: Progressive Recruitment: An ambitious...