I have a short essay in the September issue of MundoJava, which was described to me as "Brazil's best software development magazine."

The editors at MundoJava translated my essay to Portuguese, but kindly gave me permission to post my original here:

What is Fit and why does it matter? It's part of your agile bug-prevention arsenal. Unlike the traditional approaches to quality, which focuses on finding and removing defects, agile approaches focus on preventing bugs from being created in the first place. This leads to some pretty amazing results. Experienced agile teams only produce a handful of new bugs per month.

The "agile engineering practices" introduced by Extreme Programming (XP) are part of the reason. These techniques--such as test-driven development, pair programming, collective code ownership, simple design, and energized work--prevent most programming errors. They ensure that the code does exactly what the programmers intended it to do.

Eliminating programming errors is a big step, but it doesn't prevent all bugs. Sometimes programmers misunderstand what is needed. Agile's idea of an involved product owner who sits with the team--an "on-site customer," in XP terms--goes a long way to preventing programmer misunderstandings. They can easily ask questions of the product owner, and she can see the team's progress and make corrections as they go.

These are great techniques, but some bugs still sneak by. Complex problem domains, such as finance or law, have a lot of nit-picky scenarios that have to programmed exactly right. In many cases, even the experts don't agree about the correct answers. In order for the programmers to create the software without bugs, they have to understand all of the possible cases and what the correct answers are. Surprisingly, even the experts haven't thought through all of the possibilities, and they often won't agree which answers are correct!

It's a recipe for bugs, and that's where Fit comes in. More than anything else, Fit is a tool for improving communication and collaboration around business requirements. Using Fit, teams discuss real-world examples of business rules in practice, and Fit automatically checks that the software does what the examples say. This conversation flushes out misunderstanding, errors, and disagreements. The automatic checks force the conversation to be rigorous, and provide documentation and ongoing confirmation.

This ability to enhance communication is Fit's most important attribute. Teams often think of Fit as a tool for testers. Nothing could be further from the truth! Fit's strength is its ability to get programmers and business experts talking to each other, disagreeing with each other, and reaching consensus together. Testers play a role in this process--often bringing up edge cases nobody had considered--but Fit is not a testing tool. It's a tool for collaboration... that happens to automatically check your results.

What is Fit and why does it matter? It's a tool for eliminating defects that arise from the confusion and miscommunication that often surround complex business requirements. It's an important part of your agile bug-prevention arsenal.