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.”
Extreme programming is a system development life cycle (SDLC) methodology that takes common sense principles and practices to the extreme. For example,
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.
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.
The information below shows the differences between the deliverables of a traditional SDLC and the extreme programming SDLC.
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.”
Order the book Extreme Programming Explained by Kent Beck. It will help you determine what you need for this environment.