Welcome to the The Art of Agile Development website. Think of this as the "special features" DVD for the book, only without the DVD. (If you haven't bought the book yet, that's okay... we won't tell if you don't.) Here, you'll find a cornucopia of bonus material, such as downloadable posters, behind-the-scenes material, and new insights.

For more bonus material, see the table of contents.

(If you're getting a 404, this chapter has yet to be posted. Try the table of contents instead.)

 Print

The Art of Agile Development: No Bugs

16 Jul, 2008

in 99 words

Rather than fixing bugs, agile methods strive to prevent them.

Test-driven development structures work into easily-verifiable steps. Pair programming provides instant peer review, enhances brainpower, and maintains self-discipline. Energized work reduces silly mistakes. Coding standards and a "done done" checklist catch common errors.

On-site customers clarify requirements and discover misunderstandings. Customer tests communicate complicated domain rules. Iteration demos allow stakeholders to correct the team's course.

Simple design, refactoring, slack, collective code ownership, and fixing bugs early eliminates bug breeding grounds. Exploratory testing discovers teams' blind spots, and root-cause analysis allows teams to eliminate them.

Behind the Scenes

Singed Egos

Inside the Book

  • No Bugs
  • How Is This Possible?
  • How to Achieve Nearly Zero Bugs
  • Ingredient #1: Write Fewer Bugs
  • Ingredient #2: Eliminate Bug Breeding Grounds
  • Ingredient #3: Fix Bugs Now
  • Sidebar: Don't Play the Bug Blame Game
  • Ingredient #4: Test Your Process
  • Ingredient #5: Fix Your Process
  • Sidebar: Making Mistakes Impossible
  • Invert Your Expectations
  • Questions
    • If novices can do this, what's stopping management from firing everybody and hiring novices?
    • How do we prevent security defects and other challenging bugs?
    • How long should we spend working on a bug before we convert it to a story?
    • If our guideline is to fix bugs as soon as we find them, won't we have the unconscious temptation to overlook bugs?
    • If we don't find any bugs, how do we know that our testers are doing exploratory testing correctly?
    • We have a large amount of legacy code. How can we adopt this policy without going mad?
  • Results
  • Contraindications
  • Alternatives
  • Further Reading

Loading...

Loading comments...