There are multiple ways of expressing the same concept in source code. Some are better than others. Refactoring is the process of changing the structure of code—rephrasing it—without changing its meaning or behavior. It’s used to improve code quality, to fight off software’s unavoidable entropy, and to ease adding new features.

Imagine a customer rushing down the hallway to your desk. “It’s a bug!” she cries, out of breath. “We have to fix it now.” You can think of two solutions: the right way and the fast way. You just know she’ll watch over your shoulder until you fix it. So you choose the fast way, ignoring the little itchy feeling that you’re making the code a bit messier.

Technical debt is the total amount of less-than-perfect design and implementation decisions in your project. This includes quick and dirty hacks intended just to get something working right now! and design decisions that may no longer apply due to business changes. Technical debt can even come from development practices such as an unwieldy build process or incomplete test coverage. It lurks in gigantic methods filled with commented-out code and “TODO: not sure why this works” comments. These dark corners of poor formatting, unintelligible control flow, and insufficient testing breed bugs like mad.

The bill for this debt often comes in the form of higher maintenance costs. There may not be a single lump sum to pay, but simple tasks that ought to take minutes may stretch into hours or afternoons. You might not even notice it except for a looming sense of dread when you read a new bug report and suspect it’s in that part of the code.

Left unchecked, technical debt grows to overwhelm software projects. Software costs millions of dollars to develop, and even small projects cost hundreds of thousands. It’s foolish to throw away that investment and rewrite the software, but it happens all the time. Why? Unchecked technical debt makes the software more expensive to modify than to reimplement. What a waste.

XP takes a fanatical approach to technical debt. The key to managing it is to be constantly vigilant. Avoid shortcuts, use simple design, refactor relentlessly... in short, apply XP’s development practices (see Chapter 9).

Some activities invariably stretch to fill the available time. There’s always a bit more polish you can put on a program or a bit more design you can discuss in a meeting. Yet at some point you need to make a decision. At some point you’ve identified as many options as you ever will.

Recognizing the point at which you have enough information is not easy. If you use timeboxing, you set aside a specific block of time for your research or discussion and stop when your time is up, regardless of your progress.

This is both difficult and valuable. It’s difficult to stop working on a problem when the solution may be seconds away. However, recognizing when you’ve made as much progress as possible is an important time-management skill. Timeboxing meetings, for example, can reduce wasted discussion.

XP views a potential change as an opportunity to exploit; it’s the chance to learn something significant. This is why XP teams delay commitment until the last responsible moment.^[8]

Note that the phrase is the last responsible moment, not the last possible moment. As [Poppendieck & Poppendieck] says, make decisions at “the moment at which failing to make a decision eliminates an important alternative. If commitments are delayed beyond the last responsible moment, then decisions are made by default, which is generally not a good approach to making decisions.”

By delaying decisions until this crucial point, you increase the accuracy of your decisions, decrease your workload, and decrease the impact of changes. Why? A delay gives you time to increase the amount of information you have when you make a decision, which increases the likelihood it is a correct decision. That, in turn, decreases your workload by reducing the amount of rework that results from incorrect decisions. Changes are easier because they are less likely to invalidate decisions or incur additional rework.

See Release Planning” in Chapter 8 for an example of applying this concept.

Stories represent self-contained, individual elements of the project. They tend to correspond to individual features and typically represent one or two days of work.

Stories are customer-centric, describing the results in terms of business results. They’re not implementation details, nor are they full requirements specifications. They are traditionally just an index card’s worth of information used for scheduling purposes. See Stories” in Chapter 8 for more information.

An iteration is the full cycle of design-code-verify-release practiced by XP teams. It’s a timebox that is usually one to three weeks long. (I recommend one-week iterations for new teams; see Iteration Planning” in Chapter 8) Each iteration begins with the customer selecting which stories the team will implement during the iteration, and it ends with the team producing software that the customer can install and use.

The beginning of each iteration represents a point at which the customer can change the direction of the project. Smaller iterations allow more frequent adjustment. Fixed-size iterations provide a well-timed rhythm of development.

Though it may seem that small and frequent iterations contain a lot of planning overhead, the amount of planning tends to be proportional to the length of the iteration.

See Iteration Planning” for more details about XP iterations.

In well-designed systems, programmer estimates of effort tend to be consistent but not accurate. Programmers also experience interruptions that prevent effort estimates from corresponding to calendar time. Velocity is a simple way of mapping estimates to the calendar. It’s the total of the estimates for the stories finished in an iteration.

In general, the team should be able to achieve the same velocity in every iteration. This allows the team to make iteration commitments and predict release dates. The units measured are deliberately vague; velocity is a technique for converting effort estimates to calendar time and has no relation to productivity. See Velocity” in Chapter 8 for more information.

[Goldratt 1992]’s Theory of Constraints says,in part, that every system has a single constraint that determines the overall throughput of the system. This book assumes that programmers are the constraint on your team. Regardless of how much work testers and customers do, many software teams can only complete their projects as quickly as the programmers can program them. If the rest of the team outpaces the programmers, the work piles up, falls out of date and needs reworking, and slows the programmers further.

Therefore, the programmers set the pace, and their estimates are used for planning. As long as the programmers are the constraint, the customers and testers will have more slack in their schedules, and they’ll have enough time to get their work done before the programmers need it.

Although this book assumes that programmers are the constraint, they may not be. Legacy projects in particular sometimes have a constraint of testing, not programming. The responsibility for estimates and velocity always goes to the constraint: in this case, the testers. Programmers have less to do than testers and manage their workload so that they are finished by the time testers are ready to test a story.

What should the nonconstraints do in their spare time? Help eliminate the constraint. If testers are the constraint, programmers might introduce and improve automated tests.

Agility—the ability to respond effectively to change—requires that everyone pay attention to the process and practices of development. This is mindfulness.

Sometimes pending changes can be subtle. You may realize your technical debt is starting to grow when adding a new feature becomes more difficult this week than last week. You may notice the amount and tone of feedback you receive from your customers change.

XP offers plenty of opportunities to collect feedback from the code, from your coworkers, and from every activity you perform. Take advantage of these. Pay attention. See what changes and what doesn’t, and discuss the results frequently.