ONLamp.com
O'Reilly Network.oreilly.comSafari Bookshelf.Conferences.
Articles Weblogs Books Learning Lab News  

Join us at the O'Reilly Emerging Technology Conference, Feb. 9-12, in San Diego, CA.

Search

ONLamp.com
All of O'Reilly
 
 Advanced Search »

Login
Register
Manage Newsletters

Essentials

All Articles

What is LAMP?

The Best of ONLamp.com

Register

Newsletters

Learning Lab

Linux Commands


ONLamp Subjects

Linux

Apache

MySQL

Perl

PHP

Python

BSD

Security


ONLamp Topics

All Articles

App Development

Database

Programming

Sys Admin


ADC
0
Headlines
0

Sites
LinuxDevCenter.com
MacDevCenter.com
WindowsDevCenter.com
Mozilla DevCenter
ONDotnet.com
ONJava.com
ONLamp.com
Apache
BSD
MySQL
PHP
Python
OpenP2P.com
OSDir.com
Perl.com
Policy DevCenter
Web DevCenter
Wireless DevCenter
XML.com
WebServices.XML.com

Resource Centers
Perl
Java
Python
C/C++
Scripting
Web
Digital Media
Web Services
XML
Oracle
SysAdm/Networking
Security
Databases
Linux/Unix
Macintosh/OS X
Windows
.NET
Open Source
Wireless
Bioinformatics

Atom Feed
RSS Feed
RSS Feed
Using our RSS Feeds


Related O'Reilly Books
Traveling to
a tech show?

Discount Hotels
California Hotels
New York City Hotels
Canada Hotels
Chicago Hotels
Hotel Discounts
Miami Hotels




   Print.Print
Email.Email article link
Discuss.Discuss
Blog this.Blog this
Extreme Programming Pocket Guide

Five Lessons You Should Learn from Extreme Programming

by chromatic, author of Extreme Programming Pocket Guide
07/31/2003

  1. Code for Maintainability
  2. Know Your Status
  3. Communicate Early and Often
  4. Do Things That Matter
  5. Fix Your Most Important Problem First

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.

Code for Maintainability

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.

Related Reading

Extreme Programming Pocket Guide

Extreme Programming Pocket Guide
By chromatic

Table of Contents
Index

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.

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.

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.

chromatic is the Technical Editor of the O'Reilly Network.

O'Reilly & Associates recently released (July 2003) Extreme Programming Pocket Guide.

Return to ONLamp.com.
Sponsored by:

Get Red Hat training and certification.

Contact Us | Advertise with Us | Privacy Policy | Press Center | Jobs

Copyright © 2000-2004 O’Reilly Media, Inc. All Rights Reserved.
All trademarks and registered trademarks appearing on the O'Reilly Network are the property of their respective owners.

For problems or assistance with this site, email help@oreillynet.com