The Mistake is Not Making a Mistake

There is a quite thought provoking section in the book PeopleWare: Productive Projects and Teams (DeMarco & Lister) called “A Quota for Errors”. In starts with:

For most thinking workers, making an occasional mistake is a natural and healthy part of their work. But there can be an almost Biblical association between error on the job and sin. This is an attitude we need to take specific pains to change.

This is quite a profound statement. How many organisations have methodologies that have become so rigid that – in an effort to drive out errors – they have killed off innovation, free thinking and creativity. But when is an allowance for an error a sign that standards are slipping and code reviews are not robust?

Good question. If you tell the team it’s okay to make errors. Can you see the number of failed code reviews reaching new highs and performance reviews becoming less pleasant. But the more I think about it there is an important principle here.

Why would you create an environment for people to make mistakes? An environment to take risks, think of new ideas and approaches. Otherwise:

Fostering an atmosphere that doesn’t allow for error simply makes people defensive. They don’t try things that may turn out badly.

Another great quote, they won’t try anything new, the risk of failure outweighs the risk of success.

 With errors, there is the good and bad. Cutting corners – no error handling, no rollback, not closing connections, basic code indentation – these are lazy errors. Mistakes someone makes when they are not being careful. These errors have cowboy written all over them.

Good errors occur when the Developers are thinking, trying something new, a different approach, a different library, code module, technology, whatever. They see a gap in the current approach or an opportunity to improve a methodology, the go for it. If they fail. They tried and failed. As opposed to did nothing, learnt nothing, gained nothing and won’t try again. If they succeed, what’s the outcome, the saving, the benefit, the payback. What’s the return on the risk now, next month, next year, next piece of software that needs building.

The average level of technology may be modestly improved by any steps you take to inhibit error. The team sociology, however, can suffer grievously.

So a somewhat late New Year’s resolution, allow the team to make errors, allow them to be human – not a component in a production line – and see the benefits.