Why failure is important

Failure is a word with negative connotations — of targets not met, standards not reached, goals not achieved. But when it comes to software development, failure is an important part of the process, and an important stepping stone along the way to finding success.

That's not to say you should aim for failure or rejoice in it, but nor should you consider it demoralising. Like developing a new drug or sculpting a statue -building software is an experimental process, and the solution doesn't fully emerge until you're some way down the track.

Some of the things you try won't work — that's inevitability, no matter how skilled or experienced you are. The crucial part of working on software projects is not avoiding failure but knowing what to do with it: how do you react to reaching a roadblock?

Even with a clear objective, the route to it may not be immediately apparent. At some point it is likely that features will be added that aren’t seamless, screens will be built that don’t quite fit the bill, and processes will be implemented that are just too complicated. Let it be clear, this is not necessarily a failing on the part of the team, but a consequence of human nature, of trial and error.

So what next? Often the best course of action is to remove the feature/screen or process in question. Clear the decks, delete the code and free programmers up to concentrate on what's important. It's tempting to leave features in "just in case", but maintaining software you aren't going to need has hidden costs.

As software developers our principle raw material is headspace - the time and space to think things through properly. Good things happen when programmers go back to the drawing board. Take Brian Acton and Jan Koum for example, the former Yahoo engineers who applied for jobs at Facebook. Having ‘failed’ at their original application to Facebook— they took their failure as motivation and went on to build WhatsApp, later selling it to Facebook for a cool $19 billion some five years later.

Acton and Koum didn't take their failure to get into Facebook to heart (though it was no doubt a disappointment at the time). Instead, they used it as an opportunity to reimagine social networking and build something new.

Even within a system, if a feature or page isn't helping- it's better to remove it. We're proponents of the idea that the best code is no code, or at least as little as possible — more code means more bugs to squash, more maintenance to carry out, and a more complicated upgrade process. It also means bigger teams and more potential communication breakdowns.

Yet recognising failure and cutting out code is not often encouraged in corporate environments — failure is more likely to be covered up and features are more likely to be left in place in order to save face. It's not an approach we agree with. When Steve Jobs returned to Apple he cut the number of products they sold from 350 to 10. This ruthless focus on doing a few things really well took Apple from the brink of bankruptcy to the worlds most valuable company. But you don't get there without a few failures on the way.