Extreme Programming Pocket Guide

Chapter 4. Assuming Sufficiency

Software development is often a competition for time and resources: managers fight developers, developers fight managers, and everyone fights customers.

XP asks a different question. Given sufficient time and resources, how would you develop software?

Sufficient Time

XP enables sufficient development time. Rather than scrambling to meet an impossible deadline, work at your normal pace. The amount of work you can do is constant—the only real question is which work to do. Adjust scope to fit the schedule to the available time.

Sufficient Time also implies that change is inexpensive—that the customer can change his priorities cheaply and you can change the code easily. Several XP practices combine to produce flexible code.

XP attempts to produce the most valuable software for the time and resources invested. To do this, you must be able to estimate accurately the amount of work you can actually do. The customer must be able to identify the most important work that can be done. You must be able to change both the schedule and the software as the customer’s needs change. Of course, it may be impossible to fit the desired work into the schedule. XP attempts to identify this as soon as possible so that the customer can stop the project before he invests too heavily without payoff.

XP projects work in very short cycles, reducing the length of time between an action and its analysis. There are many opportunities to judge the current progress and to make course corrections. The project starts producing results almost immediately. You can see if you’re on the right track very soon. You’ll have plenty of time if you make the most of the time you have.

Sufficient Resources

XP enables sufficient development resources. The number of developers governs the amount of work you can do. Adjust scope to fit the project to the available resources.

Developers provide estimates for very small tasks. Refine your estimates by comparing them to the actual time spent on the tasks. With a little experience, your estimates will be good enough for planning purposes. Your estimates give the customer a resource budget that he can spend on scheduling features.

Resources tend to increase with time, in the sense that you’ll gain more experience with the project. You’ll learn more about the problem you’re solving, develop new techniques, and refine your skills. As the code evolves, it will be easier to add new features—especially as you solve the customer’s most pressing needs.

Constant Cost of Change

XP ensures that the cost of change remains constant over time. In other words, it will cost about as much to add a feature next year as it would to add that feature today. If this is true, you can defer features until they’re really necessary, without worrying about the cost of waiting. XP invests time and resources where they will produce the most results.

XP reduces the cost of change by seeking out continual customer feedback. The customer will receive a working version of the code as soon as possible, often just a few weeks after the start of the project. Development then becomes a process of refinement. Regular, frequent releases add new features and improve existing features. The customer watches his requests take shape. Business changes are reflected in code and delivered to end users with surprising speed.

The development cycle provides regular, frequent opportunities for the customer to adjust the schedule to match business needs. He can change the project’s priorities at any point. He can even stop the project when he’s recouped his investment. At the same time, developers are constantly refining their understanding of the software and the business problem.

XP produces flexible and maintainable code by emphasizing simplicity and verification. Rigorous testing gives everyone confidence that the code meets customer requirements. Individual pieces work well together. Future changes won’t mysteriously break the existing, correct behavior. Developers can improve the code with small, measured changes, and are free to address new requirements fearlessly.

Developer Effectiveness

Good software requires good developers. Effective development requires programmers of ability, broad knowledge, and productivity. XP takes advantage of the best practices of programming, introducing and reinforcing good developer habits. A group of average developers who are dedicated and committed to producing good software can become a highly productive team.

XP’s practices form a network of checks and balances. For example, developers work in pairs. Two sets of eyes review every line of code. Two brains evaluate each solution. Ideas flow freely—they’re analyzed and are implemented if they make the project simpler, more correct, or more maintainable.

XP sets up several feedback loops in the coding process. Disciplined tests provide immediate results and probe the project’s health. Estimates are soon explored, leading to better accuracy. The entire codebase—design and implementation—is open for improvement when it’s needed. Expect your project to evolve into its optimal form. Watch change happen and learn from your mistakes. This will quickly build valuable experience.

XP removes several barriers that hamper effective development. By trusting the technical decisions of developers and the business decisions of customers, XP limits the responsibilities of each group. By agreeing to adjust the scope dial while leaving time alone, XP avoids overwork and frustration that sap morale and reduce efficacy. By valuing honesty, improving communication, and working more closely as a team, XP will help you succeed—as a team.

Freedom to Experiment

XP assumes that the entire team—managers, developers, and customers—has the freedom to experiment. This affects every decision, big and small. XP can flourish only in a culture where it is acceptable to ask “Is there a better way to do this?” and “What can we stop doing and still succeed?” There is no reward without risk.

XP assumes that teams have the freedom to remove obstacles. For example, many teams prefer to work in large, open areas. It may be difficult to escape cubicles, but removing physical barriers to collaboration can improve productivity dramatically. If you can overcome this problem and demonstrate that the change had a positive effect, you may find it easier to remove further obstacles.

XP attempts to reduce risk without waiting for perfect solutions. If good enough is good enough, why wait? Aim in the right direction and make course corrections as you go. Projects require a small, up-front investment of time and resources. They will begin to deliver usable results within a few weeks. The customer can immediately make adjustments toward a better solution, or even end the project if necessary.

XP reserves the right for teams to change their culture. Keep in mind the goal: to produce effective software by doing what’s really important. XP sets guidelines to determine what’s important, but it’s up to you to apply them to your team.