The Last Line of Defense, in Soccer and Bug Catching...

I was a goalkeeper on my soccer team from about 8 years old through college. I didn't always like being the goalkeeper, but my coaches and teammates always liked putting me in goal anyway. It was stressful, nerve-wracking, and either very boring or way too exciting. Sure, sometimes I had my hero moments when I made a really great save, but other times I messed up and let a goal through that should have never gone through. Whenever I had a bad game my parents would remind me that "the ball has to pass through 10 other players before it gets to the goalkeeper." So, 10 other people messed up before the ball got to me, unfortunately my mess up as the goalkeeper was the most memorable and dramatic one.

So, how does this relate to a software project?

Well, the ball is a bug and the soccer team is each member and phase of the project. In many cases the bugs that are found post-launch are blamed on programmers or testing team, when in fact they could have been caught much earlier on.

What is the first line of defense? The offense.

From the very beginning, be sure to clarify requirements with the project stakeholders, the client or the end users. When possible, use prototyping to demonstrate how the application will work. Using a prototype will hopefully dig up more questions that will lead to defining the product more carefully.

Next, as you move back to the mid-fielders, make sure the technical, functional and design specifications are closely married to the requirements. Review specs with the client/users to ensure that everyone is on the same page with what the end product will be. A bug can just as easily be created in this phase of the project, by missing a critical requirement or misinterpreting the user's needs.

The defense is the programming team. Make sure the level of quality is consistent in this phase by holding peer code reviews, functionality checks and regularly merging all of the elements back in to be tested together. Programmers who develop independently might build perfect pieces of an application, but if not brought together often enough those incongruous pieces are useless.

The last line of defense, the goalkeeper, is the tester teamed with the programmer assigned to fixing those bugs. Of course this stage is critical, and to ensure the highest level of quality you want to make sure there is proper testing documents, adequate time to properly test and fix and then test again. Ideally there will be a full system test each time a new set of bug fixes is rolled out.

All of these players in the project are human, and they can all make mistakes. I haven't yet found a software solution to ensure that requirements are completely met 100% from start to finish, without some level of human intervention.

So, next time one of your end users finds a bug or the opposing team scores a goal...don't just blame it on the goalkeeper, take a look at a whole picture and figure out where else the mistakes could have been made and how to avoid them next time.

(as the referee whistle blows, the next play begins....)

good luck!