It’s time to do something about all these bugs. The dev-team keeps shipping bugs every other month – Manny thought to himself. He had been managing a team for almost six months now and his gut-feeling told him they were on a slippery slope to a really warm place.

Manny walked back and forth in his room, trying to come up with an idea on how to stop this madness. Because it was madness. The team could easily spend two weeks fixing bugs every release. And sometimes they did.

He came up with nothing and strode over to the window beside his desk. Just as he was about to enter his seat he spun around, grabbed a pen and paper from his desk and ran down to the war room.

He liked the term ‘war room’. Everybody else called it the developers room. But Manny liked the tone and implication of the term war room, he realized as he entered it.

Hey, listen up folks! This weekend will be a bug-fix weekend. The name really says it all, but come to me if you have questions. Manny scans the room to see if he has everyone’s attention It starts Saturday morning … If you can’t attend, write that down beside your name here, on this list. If you can, write down your preferred Pizza.

Manny knew all programmers were suckers for pizza and he had another surprise for them. Everybody that attends get a dinner for two on a restaurant of your choice … he savored the rest of the sentence … per day. So, you can get 2 restaurant visits, or 4 persons in total. He could have sworn he heard a low ‘Ooooh’ from the other side of the room. But he didn’t linger long enough to really hear what people talked about.

He walked out of the room and he knew it would be a success!


Manny might have all the right intentions in the world. Wanting this to be a success. Building some team spirit or whatever. Trying to raise the quality of the product. What he doesn’t realize is that this will have the opposite effect. By running this bug-squash event, he is saying that it is OK to produce code with errors in it. And he has begun institutionalizing waste this way.

Let’s make one thing clear though. It’s OK to make errors. It should be OK to fail. But what Manny does is a totally different story. He communicates that quality is something that can be added later. If needed.

He also communicates that quality isn’t important enough to pay attention to all the time. It is something you can add later, like paint. What he probably hasn’t realized either is that quality is much more expensive to ‘test in’ later. And that the ‘testing in’ approach also results in lower quality.

Software is expensive as it is already. We don’t need waste in the form of bugs to drive costs up further.

Refactored Solution

Q: If quality is expensive to ‘test in’. What is the correct approach then?
A: Build a quality product from the beginning.

Mistake proofing

People are human and we make mistakes. While mistakes aren’t avoidable, defects are. Defects result from mistakes reaching an end customer. So, the goal is to create a process where a defect never reaches the end customer. Doing so is the responsibility of the development team.

This can be achieved by combining various mistake proofing techniques. Now there is no single one technique that can stops all defects from reaching customers. It’s a combination of several ones, fit for the purpose.

Categories of mistake proofing

There are two types of mistake proofing techniques. One is prevention, the other one is detection. If you think them both, you might recognize a few from your every day life. It’s full of examples, both prevention and detection devices.

Detection devices doesn’t enforce correction, They merely signals problems. Take a modern car for instance. When you’re backing up and you come close to a curb or another obstacle, a beeping starts. This signals a warning to you as a driver. It doesn’t kill the engine, although it probably could.

Prevention devices works differently, they remove the need to correct a mistake. Like a power cord. There is only one way you can plug that into a wall socket. If you live in Sweden, where I live, there is actually two. But both ways work. Hence no mistakes are made and none need to be corrected.

Software mistake proofing

In software there are several techniques for mistake proofing. And those techniques are what you need to put to work when improving quality. You will want to design a process where defects doesn’t reach the customer.

Here are some of my favorite techniques. Can you see which category they belong to. Prevention or detecteion.

  • Test Driven Development
  • Pair Programming
  • Regression tests
  • Continuous Integration
  • Customer tests

About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

6 responses »

  1. Tobias Fors says:

    Great article Ola! /Tobbe

  2. Anders Ivarsson says:

    Awesome article Ola, spot on!

    / Anders

  3. stevenlist says:

    Wonderfully written. Well done. And the content is good, too. 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s