Whole books have been dedicated to the topic of Extreme Programming. I browsed through a few of them, leaving me rather puzzled. It is like reading a brochure on alternative healing, saying how I will be slim, fit and a success just by embracing my inner self or some Hidden Light.
I know the benefits - ability to put a prototype together quickly, not needing long period of planning, and etc, but I am still confused about the methods. There is something about pair programming, and from my knowledge that it works, but that’s can’t be all to Extreme Programming.
So, what is it, really? How does it work? Does it really work?
I haven’t done it myself, but one project group at my company went through this a few years ago. Whether because it was poorly implemented or the methodology is faulty, I can say that it didn’t work here. IMHO, in the end it’s just another flavor du jour promising incredible results that don’t happen in reality.
Extreme Programming is a collection of strategies that cover everything from how a team is assembled to how code gets written. Under extreme programming methods, projects basically get designed on the fly with feedback from the “customer”. That is, someone who represents the needs of the end user of the software is a member of the team and may constantly change the requirements. Much of the design work is basically the old “compose at the keyboard” model done by paired programmers. Unit testing is built, usually with the “build the test first” mentality.
IMO, extreme programming is a great thing for some people and projects, and it’s pointless for others. It’s not a “better” way of doing things, just another method that may produce better results in some situations. Some coders are able to work in pairs; some aren’t. Some coders are able to design on the fly while coding; some aren’t. Some projects work best with flexible requirements and constant input from end users; some don’t. I think the only thing about extreme programming that you can say is absolutely right is the philosophy of test, test, test. I can’t think of a programming project that wouldn’t be better off with a built-in set of unit tests, most of us just don’t take the time to do it.
Also, try not to think of extreme programming as an all or nothing proposition. It’s really a collection of software design methods, and you can pick and choose the bits that work for you. A real extreme programming zealot might not let you use the buzzword if you don’t implement every link in the chain, but who cares. If the team building and design strategies work for you but you want more detailed high-level designs and individual coders, great. If you want to add unit tests but have them built by a separate QA team, great. Extreme programming isn’t just some half-baked “self-help” strategy that one guy came up with to sell books. It’s based on real-world programming experience and all the things included have their benefits, but you just have to choose which components work for you and which don’t.
The most central goal of XP is to reduce the cost of change to the development cycle. Requirements changes? Incorrect assumptions? These are the potential problems XP aims to solve. XP seeks to identify these changes early and lower the cost of integrating them into your development cycle. Within other software process frameworks, a change to requirements could be a huge undertaking.
Pair programming, continuous integration, small releases, on-site customers and refactoring are probably the central “methods” of XP. The idea is to always be creating, changing, and improving until you have software that your customer is pleased with.
I’m less familiar with the formal testing and code review guidelines in XP so maybe someone can come along with more background and fill in the gaps.
It mimics what the average intelligent slacker student does in his programming class, do his homework the day before class.
Just kidding, sorta
The idea behind extreme programming is that programmers all program differently. It may be good practice to document your work as you do it but it’s slow and boring. The fun part is the programming itself. Some parts of the programming is boring in itself so one “steals” code with or without attribution. So a program designed to plot the placement of sprinkler heads on a lawn can be adapted to plot the placement of soldiers on the battlefield. Documentation is done last. :eek:
