Chapter 1. XP in a Thousand Words


Don Wells

Copyright © 2003, Don Wells. All rights reserved.

For some people Extreme Programming (XP) is a new set of rules, for others it is a humanistic set of values, and to some it is a very dangerous oversimplification. XP comes to us at a time when we find computer programming to be a bottleneck. Businesses demand bigger systems faster to gain a competitive edge. The rate at which we can create this software often determines how fast new business opportunities can grow. There have already been many changes in the way software is created over the last few decades, but few have represented such a large change. XP is more than rules or values it is a reengineering of software development in response to extreme new requirements for our craft.

The most disputed foundation of XP is the idea of doing today only what is needed today. Now before the gentle reader jumps up with fists clenched, we should point out that this doesn't mean there is no designing and no planning. Both of these activities are even more important in XP than in other methods. Actually, the biggest impact of XP is on the cost of the system over time. One of the more important aspects of the business of software is the idea of a life cycle and how cost relates to it. XP proposes new ways to address this life cycle cost and a way to get the most for every dollar we have spent to date for an early delivery or if new development needs to be stopped.

A commonly misunderstood part of XP is the stance on documents. Often it is interpreted that we should write no documentation whatsoever. This is ridiculous. XP isn't about not writing documents it is about writing more effective documentation. In most cases this results in not writing a document, because a more effective form can be used instead. Much of a project's documentation can be remembered by the team members and communicated to new team members in a conversation. A document cannot be changed nearly as fast as the ideas held in a team's collective mind. A document cannot be accessed as fast as shouting out a question and getting a response. This is not to imply there is a lack of solid documentation. On the contrary, there is a great deal in the form of automated tests, well-crafted code, and even documents, when appropriate.

This idea of relying on the team and the collective mind is indeed controversial. Not too long ago, one programmer working alone could create software that would become an overnight success. Times have changed. No one person can create an entire system and deliver it to the marketplace in time to be of value to anyone. With the rise of the team comes the need for understanding teamwork. XP stresses ways to enable a team to come together and work as if they were a single entity. The individuals who make up the team may change, but the team itself endures without faltering, making steady, dependable, predictable progress.

Don't do anything without feedback. Many of us take this concept for granted in our daily lives. We see, hear, and feel what is happening around us and use that rich information as a guide. Software development is no different, but we must expend the effort to put appropriate sources of feedback in place. We see, hear, and even feel as we move the mouse and click it to interact with our programs. But we are fooled. Our senses don't provide us with rich information about the code being tested. Programs don't exist in our physical world, so we must extend our senses into the world of software by writing code. We need tools like JUnit to translate the type of feedback we need for software development into the type of feedback our senses can assimilate.

Consider the related idea of not waiting till the end of the project to start testing in fact, let's completely reverse that and start testing first. We need feedback to monitor our progress and guide us during the project. Knowing what to test and how to test is a valuable skill. Many programmers are not required to do a thorough job of testing their own software. It is often left to a separate quality assurance (QA) group or even the unsuspecting customer to find problems. This must change if we are going to deliver faster. Programmers must learn how to test their software well enough to change their mind-set into one of creating tests even before the code. With or without QA, the team is still responsible for a complete and thorough job of testing.

An XP project is managed with concentric loops of planning and feedback. The "test first, code second" cycle is one example. A test is a plan for what we will code next. We often forget that planning is about predictions and that a prediction not based on historical data is just a guess. The only way to know how long something will take is to make a measurement. We plan only in the presence of a measurement, and we revise our plan whenever we get a new measurement. It is also important to be sure that the right measurement is made. Make the most of the data you have to predict the future. Don't fool yourself into making guesses.

XP is about some new rules, some old forgotten rules, more humane values, and of course teamwork. But there is also more, much more. We have only skimmed the surface here. There are many new ideas about how to do things better and more reliably. We must stop and think about what we are doing and question why we do it. If we take anything away from XP, we should take away the attitude of finding new ways to do more of what helps us produce software and less of anything that holds us back.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net