• Next: Incremental Requirements
• Previous: Estimating
• Up: Table of Contents

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.

Developing

Imagine you've given up the world of software to become a master chef. After years of study and practice, you've reached the top of your profession. One day, you receive the ultimate invitation: to cook for 500 attendees at a $10,000-a-plate fundraiser.

A limo takes you from your chartered plane to the venue and you and your cooks walk confidently into a kitchen... only to stop in shock. The kitchen is a mess: rotting food, unwashed cooking implements, standing water in the sinks. It's the morning of the event. You have twelve hours.

What do you do? You roll up your sleeves and start cleaning. As soon as the first space is clear, a few cooks begin the longest, most complicated food preparation. A few more head to the market to get fresh ingredients. The rest keep cleaning. Working around the mess will take too long.

It's a lesson you've learned from software over and over again.

Software development requires the cooperation of everyone on the team. Programmers are often called "developers", but in reality everyone on the team is part of the development effort. When you share the work, customers identify the next requirements while programmers work on the current ones. Testers help the team figure out how to stop introducing bugs. Programmers spread the cost of technical infrastructure over the entire life of the project. Above all, everyone helps to keep everything clean.

The best way I know of to reduce the cost of writing software is to improve the internal quality of its code and design. I've never seen high quality on a well-managed project fail to repay its investment. It always reduces the cost of development in the short term as well as the long term. On a successful XP project, There's an amazing feeling—the feeling of being absolutely safe to change absolutely anything without worry.

Here are nine practices keep the code clean and allow the entire team to contribute to development:

• Incremental Requirements allow the team to get started while customers work out requirements details.

• Customer Tests help communicate tricky domain rules.

• Test-Driven Development allows programmers to be confident that their code does what they think it should.

• Refactoring enables programmers to improve code quality without changing its behavior.

• Simple Design allows the design to change to support any feature request, no matter how surprising.

• Incremental Design and Architecture allows programmers to work on features in parallel with technical infrastructure.

• Spike Solutions use controlled experiments to provide information.

• Performance Optimization uses hard data to drive optimization efforts.

• Exploratory Testing enables testers to identify gaps in the team's thought processes.

"Developing" Mini-Etude

The purpose of this étude is to practice reflective design. If you're new to agile development, you may use it to understand your codebase and identify design improvements, even if you're not currently using XP. If you're an experienced agile practitioner, review Chapter 15 and use this étude to discover process changes that will help your team improve its approach to design.

Conduct this étude for a timeboxed half-hour every day for as long as it is useful. Expect to feel rushed by the deadline at first. If the étude becomes stale, discuss how you can change it to make it interesting again.

This étude is for programmers only. You will need pairing workstations, paper, and writing implements.

Step 1. Form pairs. Try to pair with someone you haven't paired with recently.

Step 2. (Timebox this step to 15 minutes.) Look through your code and choose a discrete unit to analyze. Pick something that you have not previously discussed in the larger group. You may choose a method, a class, or an entire subsystem. Don't spend too long picking something; if you have trouble deciding, pick at random.

Reverse-engineer the design of the code by reading it. Model the design with a flow diagram, UML, CRC cards, or whatever technique you prefer. Identify any flaws in the code and its design, and discuss how to fix them. Create a new model that shows what the design will look like after it has been fixed.

If you have time, discuss specific refactoring steps that will allow you to migrate from the current design to your improved design in small, controlled steps.

Step 3. (Timebox this step to 15 minutes.) Within the entire group of programmers, choose three pairs to lead a discussion based on their findings. Each pair has five minutes.

Consider these discussion questions:

• Which sections of the code did you choose?

• What was your initial reaction to the code?

• What are the benefits and drawbacks of the proposals?

• Which specific refactorings you can perform based on your findings?

• Next: Incremental Requirements
• Previous: Estimating
• Up: Table of Contents