Outside the box

Is perfection really so hard to achieve that you shouldn't even try?

There's a new fad in the world of Software Development and every company that's worth its salt seems to be jumping on the band wagon. The exact phrasing differs slightly from place to place, but it usually goes something like this:

Done is better than Perfect

The idea is quite simple and I fully understand the sentiment behind it, but I completely disagree with the message that it sends out.

Are "Done" and "Perfect" mutually exclusive; the inference is that we can only have one, and not the other? That the pursuit of perfection is so challenging that we just shouldn't waste time trying to achieve it? You can analyse it extensively.

Some will argue that I'm missing the point that they are trying to make about the need to release, and maybe I am, but I feel that when you communicate with a message as strong as this that on at least some level all people will over-analyse it, and reach potentially alarming conclusions.

The IT industry does not have a problem with people sitting on software, fettling with every last detail in a never-ending pursuit for perfection. You don't have to look hard to find significant flaws in any website or application, regardless of platform or company size.

I think that the majority of users would rather our posters read things like: "Fix one more defect, it will make my experience so much better".

I think that the problem that the industry has mis-identified is actually one of an abundance of indecision, rather than an unnecessary pursuit of perfection.

Companies like Facebook are strong proponents of 'Done is better than perfect' - there are posters are all over their office walls saying just that. While there is no denying Facebook's success as a company, correlation does not equal causation and I ask you whether another company in another industry could get away with the decisions and mistakes that Facebook make?

You can afford to get a lot of things wrong when you've got a monopoly, or at least a significant market share, but that's something that most companies don't have the luxury of; there's almost always a viable competitor waiting to capitalise on every imperfection in their product and process.

So what would my posters say?

Strive for perfection without becoming overly obsessed by it

It sends out a more positive message and comes closer to addressing the root cause, while simultaneously promoting its own cause - it arguably isn't a perfect slogan but it serves the intended purpose, and any more time spent on it would arguably be wasted.

But while it is closer, it still doesn't really address the root cause. Nobody wants to be the person who brings down the site, costing the company money; a degree of cautiousness, indecision and fear is somewhat expected. With great power comes great responsibility.

If a company is keen to achieve frequent releases with a degree of controlled risk it shouldn't be achieved by saying 'imperfect releases are good', but rather by having a culture where 'mistakes are ok, as long as we learn from them'. It's not a problem that can be solved by posters, but rather should be an engrained culture that is fully supported and embraced from the bottom to the top of the organisation.

Sometimes the biggest critics aren't management, but rather a team's peers who openly criticise release decisions. Granted this is sometimes warranted, but their energy would be better spent creating a more supportive and collaborative environment where mistakes don't happen in the first place. As William Rogers did after the Challenger Disaster.

One of the biggest threats that comes from accepting imperfect software is that the line between what is acceptable and what is unacceptable becomes increasingly blurred. If we imagine an arbitrary quality (or user-satisfaction) scale of 0-100%, when you start accepting quality of 95% then you'll soon start accepting 93%, then 92%, etc., until ultimately your users choose a competitor. When you strive for perfection, it's still unlikely that you'll actually achieve it (in everybody's eyes at least) but you have at least a chance of getting close.

Imperfections are like broken windows - when you start accepting them they quickly appear everywhere

A/B testing, canary deployments (deploying to a subset of traffic as a [final] verification that the release is ok) and many other tools available to us today make achieving perfection easier than ever to achieve, and yet the industry seems content on using these tools as justification for releasing things that just aren't right. There's only so many times that you can frustrate and disappoint 0.1% of your active users before you've done irreparable damage. Imagine if a restaurant poisoned 0.1% of their customers - how long would they be in business?

If my case wasn't strong enough on its own, Facebook is down as I write this... http://techcrunch.com/2014/09/03/why-is-facebook-down/?ncid=rss

Approaching defects in an Agile project

Defects, bugs, glitches or even "features". What you call them depends on your background but if you're in the IT industry then there is one thing that is almost certain. You've come to accept them as being "inevitable".

I've never agreed with this, and so a couple of months ago I pitched an idea to one of my project teams. It's something that's been in the back of my mind for quite a while: "Let's not accept defects in our product."

It's the stuff of dreams for Product Owners, Testers and of course users. A product that does what it is supposed to without annoying quirks or crashes.

I wasn't sure if I was being delusional or naive in what I wanted to do, but it was worth a try. Like most teams, we had a slowly growing defect backlog, but being a relatively new team our numbers were still manageable; we were still in a position of control. So, I made my pitch and the team unanimously agreed to give it a try, and since then we've worked to drive our defect backlog towards zero while continuing to deliver new features.

Defects are Technical Debt and living with them makes your team go slower, masks bigger problems and ultimately detracts from the user experience. So why do so many teams choose to accept with them?

In any Agile project, there are only two types of defect. Valid defects that you are going to fix, and ones that you aren't.

Defects that you decide you are going to fix should be fixed as soon as possible. Depending on the severity they probably fit into one of three categories.
• Fix today
• Fix tomorrow
• Fix next sprint

The majority probably go into the next sprint and if you're not going to fix it by then, then chances are you are never going to fix it, so don't bother putting it on a backlog for it to grow old or gather dust - accept the situation, mark it as "won't fix" and get on with the bigger issues or new features that your users care about.

Agile is all about iteratively developing working software, and by definition software with defects is defective software.

There is without a doubt a fine line with any piece of software when it comes to getting it "perfect" - the laws of diminishing returns come in and you can easily waste time getting caught up in trying to perfect every last detail. But that's when you make the decision to say that it doesn't need to be fixed.