Effective Simplicity

One of XP's catchphrases is "Do the Simplest Thing That Could Possibly Work." Solve the problem as simply as possible to get the job done correctly. Don't spend time creating a generalized solution (or worse, a generalized framework) if you don't need it yet.

This is hard to accomplish in practice; it's easy to play the "what-if" game and add in features you think you will need in the future. XP alleviates this with its emphasis on test-driven development and on constant customer communication. The customer has the final say over what's really necessary and what's superfluous.

This is a difficult skill to cultivate and a difficult skill to master. It's easy to confuse simplicity with baby coding or reinventing the wheel. While simplicity in one case may mean not adding a relational database backend yet, in another case it may mean reusing code from another project. However you achieve simplicity, adding features only when you actually need them often makes your software easier to change in the future.

Refactoring

XP has helped popularize refactoring—revising existing code to be cleaner and simpler while leaving its behavior unchanged. While practicing extreme simplicity may produce simple but sprawling code without a clear, coherent design, disciplined refactoring returns the code to its simplest and most effective possible form. One is simplicity of implementation. The other is simplicity of design.

If you add only the code you need only when you need it in the simplest way that could possibly work, you will often see a better design emerge than if you'd planned everything from the beginning. In an environment where your needs and goals change often, it is easier to be flexible by starting and staying simple than to try to plan ahead for every possible contingency.

Refactoring simplifies your code's design level. You do need some way of making sure you haven't broken anything, though that's another lesson.

Code Reviews

XP recommends pair programming for all important code. One of the biggest benefits of this pairing is continual code review. No matter how brilliant, talented, and experienced your developers, they won't always write the most perfect possible code. That's the idea behind refactoring. Why stop there, though? Instead of refactoring code someone else wrote without telling him, you could review each other's code, explain the changes you'd each make, and see if there's an even better approach.

A code review should ask several questions.

• How well are you adhering to the team standards?
• Did you overlook any possible flaws?
• Is there other code you could reuse?
• Could the code be simpler?
• Does it solve the problem it's supposed to solve?

Effective reviews share knowledge. It's often easier to learn what's going on in other parts of the code by walking through it with the author and seeing what everyone else is working on. Reviews also often spread new techniques through the team.

Know Your Status

One of the hardest questions to answer in any software project is, "When will it be finished?" A few programmers can get away with "When it's finished." The rest of us aren't so lucky.

There are ways to know how far you're along and if and how far you've backtracked. They don't require lots of paperwork or charts. They just need a little discipline and a little more customer involvement.

Programmer Tests

Programmer tests are written by programmers. XP suggests a practice called Test-Driven Development, where code is written only when prompted by a failing test. In other words, to add a feature, you write tests for that feature, one at a time, and write only the code necessary to pass those tests, one step at a time.

This is sometimes painful to start, but it has two wonderful effects. First, it builds up a comprehensive test suite with a fraction of the pain you'd experience writing the tests after the fact. Second, it immediately points out any harmful changes: the tests will break. (This is why it's possible to refactor mercilessly, if you have a good test suite.)

Programmer tests help you to be confident that the code you just wrote does what it should do (because it passes the tests you just wrote) and that the code you haven't touched still does what it should do (because it still passes its tests). Your new feature is complete when you can't think of any more tests to write and all the tests pass.

Customer Tests

Customer tests are slightly different from programmer tests. Instead of focusing on the implementation details at an API level, they explore the behavior of the program from the customer's point of view.

XP recommends that a developer help the customer write appropriate tests for each requested feature. As with programmer tests, when the customer tests all pass for a feature (and the existing customer tests still pass), the feature is complete.

Customer tests give you similar confidence that you haven't broken customer-visible behavior. They also give you a simple but effective way to track your progress. If the customer has asked for five features and the tests for three pass, you're 60 percent complete. Other XP techniques exist for making estimates, but relying on test successes is fairly accurate.

Communicate Early and Often

If you're truly ready to adapt to change, you need to know when it's coming. More importantly, you need to have a plan on how to adapt, whether you're a developer or the customer. You both have the same goal. You both need to let each other know when something changes.

XP recommends adding the customer to your development team. You'll work and plan together, in the same room. It's really easy to ask the customer any question that comes to mind. It's faster and easier to get a sense of his or her real needs and it's faster and easier for him or her to see how you're really doing.

Find Out What You Need to Do

The software exists to meet the customer's needs. If his needs change, you need to know to adjust your development and the software. The best way to do this is to talk directly to the customer. Capture this knowledge in customer tests, and you'll always have it at your fingertips. Run these tests often to measure your progress.

Make Your Progress Obvious

Of course, the customer's not the only one who might see changes. A feature might take longer to implement than you anticipated. It may take much less time. Whatever the case, your progress may affect the customer's decisions. If you discover that it will take six months to deliver the features the customer has requested in three months, you need to reconcile your schedules somehow.

Having a good test suite and running it often will give you a good progress report. Let the customer know where you are and what you are doing. This will help him or her decide what to do next.

Do Things That Matter

One of the biggest controversies in XP is its focus on doing only things that help you solve the customer's problem. This translates into not writing much in the way of specifications or documentation unless it's actually necessary. It also means not doing much in the way of up-front design before you know what you actually need to code.

It's easy to take this too far, never planning ahead and only ever coding. That's a mistake, though. If you need to write documentation, do it. If you need a written specification, write it. If you need to plan ahead for a tricky part of your software, break out the whiteboard, CRC cards, and draw some UML—but only if you need them.

When Coding

When you're writing code, spend your time on things that will pay off. Instead of writing code, compiling it if possible, then running a few tests by hand, turn the tests into executable code that will stay with the system. Instead of writing a general framework to solve a problem, solve the problem first. Wait until you really need the framework to pull it out.

This is very similar to the "Do the Simplest Thing That Could Possibly Work" rule. If you're running the tests and checking the output by hand, spend the time necessary to automate your tests. Know what's important and either automate away or discard everything else.

When Developing

The same rule applies to your entire development process. If your weekly four-hour meetings aren't useful, get rid of them. Many XP teams get by with a daily, ten-minute "stand-up" meeting, similar to Scrum's Daily Scrum. If tracking your estimates and your passing tests gives you enough metrics, don't worry about lines of code or defect rates.

If you really do need something (monthly milestones, for example), use them without apology. Think about what you're doing and why you're doing it. It's OK to stop doing things that aren't helping.

Fix Your Most Important Problem First

Perhaps the most important rule in XP is never expressed directly. Find what's not working on your project. You'll probably have to trace several symptoms back to the source. Once you know what the real cause is, figure out how to solve the problem. Then solve it.

Perhaps you're working with several customers who are often frustrated and surprised to see what's actually delivered several months after they request it. "This isn't what I wanted," they say, while you point to the contract. In this case, your real problem isn't that the customers have changed their minds. It's that they haven't been involved in the processes to see what's being done and to make suggestions.

Perhaps your delivery dates keep slipping. Instead of working longer hours, and cutting out code reviews and testing because "they just slow us down," your schedule may be too ambitious and the code you're producing may need too much debugging. Perhaps cutting back on the amount of work you've promised and doing more testing and more reviews will help you meet your deadline better.

Whatever the case, your project likely has at least one area for improvement. Find the real problem and fix it. Then move on to the next most important area for improvement.

Final Thoughts

While XP has a devoted following, it doesn't apply everywhere.

XP has traditionally worked best in small or medium-size teams composed of competent developers who work well together; where the customer's requirements may change frequently; and where frequent, small releases are possible. That excludes a few projects. While it's possible to adapt XP to different environments, it may take more time than you have right now. That's OK. There's still plenty to learn from XP in the meantime.

If you have an existing development process that's working well for you, stick with it. There may be ideas to borrow from XP, Scrum, CMM, or RUP that make your life easier. Do so! Whether XP is a flavor of the month or it sticks around for decades, there are plenty of people writing about it and even more adopting it. Take advantage of this to explore which XP practices, ideas, and goals will work for your team.