Mediocrity is underrated (or better is the enemy of good enough)

Many frustrating years of working on software have made me realize that there is one underlying falsehood which results in lousy software. Trying to build high quality software. This is solving the wrong problem. Undoubtedly, the most underrated characteristic of successful organizations and software is mediocrity.

All companies have a theme running through them — we are the best, we are the most innovative, we love our employees the most. We do the most interesting work, we will challenge you the most.

As far as I know, there is no company that says -” We are ok. We could be better, but thats not our priority.”

There are problems with aspiring to be the best. Everyone tries. Very, very few (obviously) make it. You can try, but generally you will never become the best. There is always someone faster, quicker and smarter than you. So essentially, you can be called a failure for failing to accomplish what you set out to do.

In most cases, your real intent is not to be the best. You want to be as good as absolutely necessary, but no better. There are problems with being the best. Being the best takes a lot out of you. Being at the top is harder than reaching there. Everyone is gunning for you. It is very, very expensive being the best.

Being reasonably good is acheivable without actually suffering a heart attack on the way. being ‘Reasonably good’ means doing as little as you possibly can and still get away with. The goal is never to make the customers go ‘wow’, but to make them say ‘eh, it does what I need it to’. After all, you have to keep in mind that your customers are pretty mediocre too. They don’t expect much more from others. Customers who consider themselves the best (or, in the worst case, turn out to be so) and demand perfection from their suppliers are such a small market segment that they are simply not worth pursuing — it does not make much business sense.

Being mediocre is sufficient in most cases. Individuals who sing praises about being the best are very often simply wasting their time. You don’t need to be the best in order to get a lot of things done. You just need to be good enough. Nowhere is this truer than in Software development, my chosen field of mediocrity.

I remember a project manager telling his team at an all hands meeting that the goal of his project development was to have zero defects. This is a large group, over 30 engineers. I left the meeting knowing that we were screwed , even though the project had not yet started.

Lets think about this a little bit. Let us assume that we were going to have a million lines of code over the next two years in this project. A trifle conservative, but good enough for our discussion. Everyone is going to spend huge amounts of time upfront ensuring that there are no defects in their code. This would mean slower software development. This in turn means there is going to be pressure towards the end to get all the features in. So there is going to be a huge spike in software development towards the end which will not get tested properly. And rather than being no defects, you are going to end up with a much larger set of defects than the average software project. Not that I am some kind of prophet, but that is exactly what happened. But almost anyone with the big picture in their head could have seen that. All save project managers who think they can be better than mediocre.

A more pragmatic (i.e. the mediocrity definition) would be that ‘we are going to try to avoid deep design and requirements defects’. Other defects will be mostly ignored. The important thing, like Microsoft has figured out, is to get mediocre products out. And then improve it little by little, making sure that you are roughly towing the mediocrity line. Being mediocre means pissing off the customer a little, but not enough to make them abandon your product.

In software, as in most other fields, mediocrity generally wins out over the most elegant. Take for example Microsoft. They chose the mediocrity path. And they have been a spectacular success at it.

So why does mediocrity win out ? One reason is it take too much to try to be the best. If you want to be the best, you can afford to be that in a very narrowly defined area. Trying to be the best in a larger scope is setting yourself up for failure. It is better to plan for mediocrity and deliver on it than to shoot for the stars and fall into a ditch carrying untreated sewage instead.

So how can we plan for mediocrity ? The first and most important step is to hire the right people. Overachievers should be politely shown the door. Anyone who aces interviews is out. (kind of like when George Costanza threw out a bunch of beautiful women when interviewing secretaries, because they were, well, too beautiful). Anyone who says they ‘want to work on a new challenge’ is out. Look for the contended, rotund engineers. They understand what it takes to be mediocre, and when to fix bugs and when to realize that its ok, we don’t really want the perfect product anyway.

Note that this is not an excuse for hiring incompetent engineers. We don’t want people who don’t understand the issues and what to do about them. We want people who understand the issues but are somewhat indifferent to solving the problems. This lends itself nicely to solving the right problems and prioritizing correctly. Really urgent issues will get attended to, because there is no choice. Niggling issues which have workarounds will be ignored, as they should be. This is unlike what the go-getter is likely to do, hurling himself or herself at problems which are best ignored. Keep in mind that solving one problem very often results in a new one surfacing, so the go-getter is no helping any. He is simply misguided. Mediocrity is a powerful solution for keeping focus on the right priorities.

It is important to keep college grads out of hiring. It really is bad for morale to have people who still have the I-can-change-the-world starry eyed look. It generally takes 3–4 years for them to fall down to the realities of life.

Process. It is important not to use Agile methods, as it actually improves quality. While a reader has pointed out that ‘It is perfectly possible to use Agile methods and be a very mediocre organization’, why take the chance ? Using a CMM or waterfall approach will ensure that there is sufficient rigidity in process to disallow attempts to achieve a high quality. Use process as a barrier to any hires who slipped through the cracks and try to over-achieve.

Finally, make sure compensation reflects the kind of engineers you want. Being in the 90% percentile of Radcliffe surveys is a killer — you will attract overachievers who might try to sneak in as being mediocre. Be in the fat and happy 50% percentile.

Once a product is released, focus on fixing bugs, not adding new features. All overacheiving companies try to do the latter and fail. Instead, have a single new functionality, maybe along the lines of ‘New ! Option to save your work’. The rest should be all bug fixes. This will dramatically improve the quality of your software and PC magazine will give it 5 stars.

Resist the urge to re-architect products. This is a bad idea. You will spend a lot of money and come up with a scalable, reusable, configurable product which is not what we should try to build. Instead, keep adding layers on existing products. Your overall productivity might suffer, but you will not be a colossal failure.

It is important to keep in mind the difference between being mediocre and aspiring for mediocrity. We want to be in the latter category. We want to be making a conscious choice to aspire for mediocrity and let that guide our decision making. Much like card counting in blackjack, ignore conventional wisdom and follow the rules of mediocrity with a steely resolve.

Many readers in the 90 percentile salary bracket will doubtless note the number of spelling mistakes in this essay. Yes. Your point ? Did it prevent you from getting my point ? My mediocrity undoubtedly teed you off a little, but did it prevent you from finishing the essay ?

I rest my case.