80% of drivers think they are better than average.

The idea of the Superiority Bias is not a new one and yet I find that it permeates software development to such an extent that it is alarming.

The quote that makes up the title of this blog is from a now famous study conducted by McCormick et al in 1986* which tested a number of drivers on eight different aspects of their driving ability.

The outcome was that 80% rated themselves as above average.

This Superiority-Bias, that we often assess ourselves to be better than we actually are, has some fairly profound implications for software and product development. It is also something the shrewd Customer should be aware of.

In my own experience in the many years I have worked in software development I have found very few programmers who actually believe they are below average. Despite the sometime staggering defect rates I’ve observed, the rank-amateur coding practices, the rampant duplication (the biggest of all programming sins) and the endless technology debates, all based on nothing more than fashion, the vast majority of programmers think they are ‘better than the norm’.

(Incidentally, I consider myself a significantly above average developer).

So, what are the possible implications for we, the Customer, in the face of the Superiority Bias?

Unless, like me, your are fortunate enough to come from a development background and are already painfully aware of this bias in everything you do, there is a good chance you will have to rely on the developers themselves (or worse still the architects and line managers) to tell you whether you have a quality product or not i.e. if the code is simple, maintainable, logical, free of duplication. Yes, the stories are delivered, the acceptance criteria pass and your test-users have liked the end result, but, will you have a maintenance problem and be faced with decreasing ROI in the months to come?

According to the Superiority Bias you can’t ask the people who wrote the code (or were closely involved) because they will naturally over-estimate the quality of their own work. And with something as complex as software its difficult to know the scale and effect of the bias.

So, whatyagonnado?

Firstly you’ll have to accept that not only will this bias inevitably exist (and you won’t be able to eradicate it) but also that software development itself is not a mature science or anything approximating it. There are no hard and fast rules about what makes good or bad code and if there were they would surely be highly sensitive to context. Even such guidance as there is can still cause endless, heated debates between developers themselves.

You can’t solve this but knowing is half the battle. Now you are aware you can adjust your expectations accordingly. So, unless your company is some sort of Mecca for devout developers of the highest order then it is a good idea to adopt the working assumption that you are definitely being delivered sub-standard code. The estimates you are being given are estimates to deliver the mediocre.

Secondly, you need to communicate to everyone that you are fully aware of the implications of Superiority Bias. You expect that the code is likely to be sub-standard and therefore that you need everyone on your delivery team to be harsh self-critics. As a Customer you will always be sceptical. Make sure everyone understand that this is part of your role.

Thirdly, try to make criticism a positive activity and reward accordingly. In fact reserve time in your backlog for this activity. At the end of a session, perhaps each day, each development team or pair should be asked to select a piece of code (randomly is best) and find something wrong with it. Accordingly you will then ensure that time is allocated to improving it. The key here is to only criticise code produced by the critics themselves. Never allow this to be one person criticising someone else’s work. What you hope to achieve here is an atmosphere of doubt. Yes, that’s right. You want to make your developers doubt everything they do. Make it clear that such critical analysis makes you happy. Be happy, be pleased. Everyone enjoys adding value and in the case of an agile delivery that should be primarily derived from pleasing the Customer.

And if they can’t find anything wrong? Well, then at least you know you have a pretty serious problem.

By the way, are you an above average Customer?

*McCormick, Iain A.; Frank H. Walkey, Dianne E. Green (1986). "Comparative perceptions of driver ability— A confirmation and expansion". Accident Analysis & Prevention 18 (3, June 1986): 205–208. doi:10.1016/0001-4575(86)90004-7.