Extreme Programming


Judy Glick-Smith
CIDM Associate

The first time I heard the words “extreme programming,” I cringed. The words conjure visions of barefooted programmers coding systems in the ultimate vacuum 24 hours a day 7 days a week, ordering pizza for every meal, with zero planning and zero communication with each other and customers. I could not have been more wrong.

According to the book Extreme Programming Explained by Kent Beck, extreme programming (XP) is “a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software.”

Principles

Extreme programming is a system development life cycle (SDLC) methodology that takes common sense principles and practices to the extreme. For example,

Principle/Practice Description
Pair Programming Coding is done in pairs of programmers so that code reviews are ongoing.
Continuous Testing Everyone–programmers (unit tests) and customers (functional tests)–tests all the time. There is no choice of whether you will test or not. If testing is not done, the project is not extreme.
Refactoring Everyone is responsible for design on a daily basis.
Simplicity Supporting current functionality only (vs. designing for the future) keeps the design simple. The person responsible for a single task is also responsible for estimating the time it will take to accomplish that task.
Metaphor Everyone works to define and refine the architecture all the time.
Continuous Integration Everyone integrates and tests several times a day.
Incremental Planning (The Planning Game) Iterations are really, really short–seconds and minutes and hours, not weeks and months and years.

Values

The five values of XP are communication, simplicity, feedback, courage, and respect.

XP uses many practices that cannot be done without communicating, such as the use of development guidelines, pair programming, unit testing, and task estimation.

XP takes the approach that simple is better. Traditional development looks to the future to anticipate the needs of the user, taking a chance that tomorrow the user will actually need that functionality. XP asks the question “What is the simplest thing that could possibly work today?” The simpler your system, the less you have to communicate and the greater the chance of developing a system your customers will actually use.

Feedback is the next XP value. One of the flaws in a traditional development environment is the occupational hazard of optimism. This results in incomplete or no testing. In an XP environment, programmers write unit tests for all the logic in the system that could possibly break. Unit tests give them minute-by-minute feedback on the state of their system. No one leaves the testing environment until 100% of the tests run without problems. Therefore, when the next pair of programmers tests their code, they know they are starting with a clean slate.

The value of courage is dependent on the first three, otherwise courage is “just plain hacking.” The team must have courage to recognize when there is a flaw in the architecture or in the code itself. They must be psychologically capable of throwing code out when they know it is not going very well. In Extreme Programming Explained, Beck advises “If the end of the day is coming and the code is a little out of control, toss it.”

The last value is respect. If members of the team do not care about each other and what they are doing, XP is doomed.

Resources

In addition to programmers and the project manager, an XP project also employs a coach. The coach’s job is to notice when people are not communicating and to help keep the lines of communication open.

Another non-traditional member of the development team is the customer. The customer actually has workspace in the same area as the developers. That customer continues to do his or her job but has the primary responsibility of supporting the XP project team as subject matter expert.

The ideal XP environment is an open area with cubicles around the periphery. Everyone sits in the open area to work and keeps their personal items in a cubicle, where they can also make personal phone calls. The open area concept facilitates communication.

Deliverables

The information below shows the differences between the deliverables of a traditional SDLC and the extreme programming SDLC.

Phase Document Deliverables in a Traditional SDLC Environment Document Deliverables in an XP Environment
Phase 1
Needs Analysis
Static system requirements document Software development guidelines (must be in place for the XP effort to be successful)
Dynamic business requirements
Dynamic system requirements
Note: These documents are continuously refined during the life of the project.
Phase 2
Design
Static functional design
Static detailed design
Dynamic functional design
Dynamic detailed design
Note: These documents are continuously refined during the life of the project.
Phase 3
Code
The code itself
Inline comments
Unit test documents (test plans, test scripts, test results)
The code itself
Inline comments
“To-do” cards to record ideas for variations
Unit test cases (stories)
“To-do” cards for variations resulting from unit test cases
Note: Development is driven by tests.
Phase 4
System Test
Test plans
Test scripts
Test results
Note: In an XP environment, system testing occurs at the same time as unit testing.
System test cases (stories)
“To-do” cards for variations resulting from system test cases
Phase 5
Implementation
User manuals
Administration manuals
Training manuals
Install guides
User manuals
Administration manuals
Training manuals
Install guides
Phase 6
Maintenance
Maintenance plan and procedures
Change request forms or system
Maintenance plan and procedures
Change request forms or system

The Role of the Technical Communicator

Because of the speed at which an XP environment moves, the technical communicator will not be the one developing all the systems documentation. The job of the technical communicator in this environment is to facilitate the documentation process by helping develop the development guidelines and creating templates to ensure easy communication. There needs to be a “context in which good designs are created, bad designs are fixed, and the current design is learned by everyone who needs to learn it.”

Additional Resources

Order the book Extreme Programming Explained by Kent Beck. It will help you determine what you need for this environment.

Also, here are some helpful Web sites:
http://www.extremeprogramming.org
http://www.xprogramming.com
http://ootips.org/xp.html

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close