Extreme Programming (XP)
Fernando Archila-Ruiz
October, 26 2004
Abstract
The following paper tries to describe how Extreme Programming (XP) as an Agile Programming method addresses design and all its required activities. Software development processes are concerned with delivering products (applications) within the constraints of what an organization thinks is most important. The process for developing software includes as a minimum the following activities: analysis, design, coding and testing.
I will show the basic rules to do Extreme Programming, No detailed written requirements, No big up-front design, Unit tests, Pair programming and No detailed written requirements. After I will try to explain how each of them works.
Extreme Programming (XP)
Extreme Programming (XP) is a new, agile programming methodology (for constructing and maintaining programs) that is becoming quite popular for medium-size programming projects. Extreme Programming (XP) might be called a sociological-oriented approach to developing software. It breaks with other, more engineering-oriented approaches to developing software, by concentrating on the interactions among clients and programmers and the interactions between programmers and other programmers. We will focus on two major aspects of XP.
Extreme Programming (XP) is a particularly rigid example of Agile Programming methodologies that was designed by Kent Beck. When he presented it in eXtreme Programming Explained (Beck, 1999) he was very firm that all the various elements were essential and must not be messed around with. Perhaps more significant is that the book was published in late 1999 (and largely written in the preceding two years) and the seminal project was the Chrysler Comprehensive Compensation or C3 project to develop a new payroll system to replace the existing one which was expected to have Y2K problems. The project was started in 1996 and had a clear absolute deadline of 1/1/2000. In fact, the project was cancelled in 2000 having never handled more than a third of the Chrysler payroll.
Extreme Programming (XP) is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. To some developers, Extreme Programming (XP) seems like just good common sense. So why the ‘extreme’ in the name?, easy , because Extreme Programming (XP) takes commonsense principles and practices to extreme levels ("A Change in the Way," 2004).
Although Extreme Programming (XP) is often presented as a list of practices, it is not a finish line (Raddinbg, 2002). We do not get better and better grades at doing Extreme Programming (XP) until we finally receive the coveted gold star. Extreme Programming (XP) is a starting line, it asks the question, “How little can we do and still build great software?. The beginning of the answer is that, if we want to leave software development uncluttered, we must be prepared to completely embrace the few practices we adopt. Alf measures leave problems unsolved to be addressed by further half measures. Eventually we are surrounded by so many halt measures that we can no longer see that the heart of the value programmers create comes from programming (Lisa Crispin, 2002) If code reviews are good, we will review code all the time (pair programming). If testing is good, everybody will test all the time (unit testing), even the customers (functional testing). If design is good, we will make it part of everybody’s daily business (refactorying). If simplicity is good, we will always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work). If architecture is important, everybody will work defining and refining the architecture all the time (metaphor). If integration testing is important, then we will integrate and test several times a day (continuous integration). If short iterations are good, we will make the iterations really, short seconds, minutes, and hours, not weeks, months, and years (the Planning Game)
The first aspect of XP is testing. In XP, tests are detailed before any code is written, so the programmers will know when coding is finished: when the code passes all the tests. This dovetails nicely with programming via iterated enhancement, because we specify the test that every new phase in the program should pass. Later, we will use driver programs to test classes. In real XP, testing is automated as much as possible.
The second aspect of XP is pair programming. In Extreme Programming XP, two programmers must always work together when writing code. One programmer is the "driver": that person is at the keyboard, and is in charge of all changes made to the program. Sitting next to the driver is the "navigator", who observes all the code that is entered, spotting problems, thinking of simplifications, helping with programming style, debugging errors, inventing/verifying tests, and generally helping with the problem solving needed to write programs. (Cabanski, 2003)
Extreme Programming (XP) is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software. It is distinguished from other methodologies by
• Its early, concrete, and continuing feedback from short cycles.
• Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
• Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
• Its reliance on automated tests written by programmers and customers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
• Its reliance on oral communication, tests, and source code to communicate system structure and intent.
• Its reliance on an evolutionary design process that lasts as long as the system lasts.
• Its reliance on the close collaboration of programmers with ordinary skills.
• Its reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.
XP is a discipline of software development. It is a discipline because there are certain things that you have to do to be doing XP. You don not get to choose whether you will write tests if you do not, you are not extreme: end of discussion.
XP is designed to work with projects that can be built by teams of two to ten programmers that are not sharply constrained by the existing computing environment, and where a reasonable job of executing tests can be done in a fraction of a day.
XP frightens or angers some people who encounter it for the first time. However, none of the ideas in XP are new. Most are as old as programming. There is a sense in which XP is conservative all its techniques have been proven over decades (for the implementation strategy) or centuries (for the management strategy).
Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned.
The fundamentals of Extreme Programming (XP) include:
• Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders.
• Writing unit tests before programming and keeping all of the tests running at all times.
• Integrating and testing the completely system-several times a day.
• Producing all software in pairs, two programmers at one screen.
• Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity.
• Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.
Why is Extreme Programming (XP) so controversial?
Well, some traditional or experimented people in developing software would do not make the cut in XP byte the following reasons:
Extreme Programming (XP) does not force team members to specialize and become analysts, architects, programmers, testers, and integrators-every XP programmer participates in all of these critical activities every day.
Extreme Programming (XP) does not force conduct complete up-front analysis and design-an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development.
Extreme Programming (XP) develops infrastructure and frameworks as you develop your application, not up-front-delivering business value is the heartbeat that drives XP projects.
Extreme Programming (XP), does not write and maintain implementation documentation-communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.
In Extreme Programming (XP), constant refactoring is necessary to support the emergent design practice, and to fight the rising "cost of change" curve by keeping the code simple. This sounds admirable, but turns out to be an immense effort hog - especially when combined with all the other XP practices that must be put in place to support this technique.
Outside the Extreme Programming (XP) world, occasional refactoring turns out to be useful, when combined with an up-front design and short iterations. Spending some time initially getting the design right means that the design stabilizes, therefore does not need to evolve as such. It will inevitably change to an extent as your understanding of the project grows, but this simply leads to an improved design, a bonus - whereas in XP the process relies on the design changing to harbor the waiting fleet of user stories.
With Extreme Programming (XP), constant refactoring (i.e. constant tinkering and redesigning of your code) is supposedly possible because the automated tests will catch out any problems. That is, the tests will catch out all the bugs that have been thought of in advance, but no others. Last time I checked, most bugs are due to things that the programmer had not thought of.
Sure, you can keep adding tests once the bug has been found by a diligent QA tester (or disparaging customer), but it is sort of too late then. Would not it be so much better to concentrate on getting the code right first time round, recognizing when that module is finished and moving on to some other part of the project that is more worthy of your attention. (Matt Stephens, 2003)
Conclusion
Software development is a constantly evolving discipline. Checking at any project management/software engineering website and we would see new ideas; new wisdom. Similarly, Extreme Programming XP is new and evolving. It is young, naive and popular amongst programmers. The trouble is, in many ways it is a leap in the wrong direction. The Extreme Programming (XP) belief is that it is okay to throw away the rulebook and redefine what is possible. That would be nice, as long as our new ideas are sound. Unfortunately, the thinking behind Extreme Programming (XP) is dodgy in the extreme.
Not using Extreme Programming (XP) to develop our applications does not have to mean turning our back on software agility. It is possible to develop software with evolving requirements, with customer involvement and high visibility of progress, in a much more robust fashion than Extreme Programming (XP) prescribes. Similarly, spending a little extra time getting the customer requirements right early on does not make the project non-agile.
Despite its flaws, XP's practices can also be tweaked to make the overall process more robust. We do not get too caught up in blind adherence to one methodology. We have not tried to end up chasing our own tail in order to be agile. Software agility is useful, but it is simply a means to an end. We have to apply whatever practices work for our project using what is right for us.
References
Raddinbg, Alan. (2002, Abril 2). Extremely Agile Programming. Computer World, 3(6). Retrieved October 24, 2004, from EBSCO Host - University of Phoneix Library Web site: http://web14.epnet.com/citation.asp (AN 6340696)
A change in the way we Program. (2004, Octuber). The Extreme Programming, 1. Retrieved October 22, 2004, from Extreme Programming Web site: http://www.extremeprogramming.org/change.html
Matt Stephens, Doug Rosenberg. (2003). Extreme Programming Refactored: The Case Against XP (1st ed.). p 214-246.
Tom Cabanski. (2003). Experience Adopting XP. Developer's Best Practices, 1(Suppl. 21). Retrieved October 24, 2004, from Interex Web site: http://www.interex.org/pubcontent/enterprise/sep01/best0901b.jsph
Lisa Crispin, Tip House. (October 2002). Testing Extreme Programming. .: Pearson Education. p 14-211
Kent Beck, Cynthia Andres. (Nov, 1999). Extreme Programming Explained: Embrace Change (1st ed.). p 13-116.
Thursday, May 03, 2007
Wednesday, October 13, 2004
Friday, September 03, 2004
Subscribe to:
Posts (Atom)