Extreme Programming

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.

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.