Five Lessons You Should Learn from Extreme Programmingby chromatic, author of Extreme Programming Pocket Guide
Every so often, a new idea strikes software development. For awhile, it was structured programming. Object-oriented programming entered the fray. Now ideas like Six Sigma, CMM, UML, and XML databases all promise to make software more reliable, easier to write, and less expensive.
It's rare that any one idea applies to every facet of the software industry and it's unlikely that any single approach will be the last advice you'll ever need. Wise developers and managers ask, though, "What could I learn from this new idea? How can I make my work simpler, more effective, or more enjoyable?"
Extreme Programming (XP) is yet another popular idea gaining press. It adapts several of the best ideas from the past decades of software development. Whether or not you adopt XP, it's worth considering what XP teaches. In no particular order, here are five lessons you should learn from Extreme Programming.
If there's a single driving goal behind XP, it's to keep the cost of change low by producing code that's easy to change. Change isn't your enemy. Perfect code isn't your goal. Your goal is to meet the customer's current needs while making it as easy as possible to meet the customer's future needs when they become known.
The first order of business on any new XP project is to get working code to the customer as quickly as possible without compromising on quality or discipline. This delivery should take place within a few weeks. The software may do very little, but it should demonstrate an actual business value and it should follow the XP rules for simplicity and provability.
Rather than attempting to get something out the door as the final, no-kidding-this-time deadline approaches, XP developers deliver new versions of the software regularly and frequently. A three-week iteration cycle is a popular rate. Instead of waiting for large migrations a few times a year, the software is delivered and improved upon every few weeks in smaller chunks. This is achieved, in part, by working in small steps but also by coding in a maintainable way.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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 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.
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.
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.
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.
chromatic manages Onyx Neon Press, an independent publisher.
O'Reilly & Associates recently released (July 2003) Extreme Programming Pocket Guide.
Sample Excerpt, Roles in Extreme Programming, is available free online.
For more information, or to order the book, click here.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.