xtreme Programming (XP) is not some nerd bungee jumping off a bridge with a laptop. It is not a geek writing code while doing back flips on a skateboard. Nothing nearly so exciting. Extreme Programming is simply a software development methodology. I’m not saying that XPers are fanatical or cultish, but I bought my copy of “Extreme Programming Explained” (Addison Wesley Longman, 2000) by noted programmer and Smalltalk guru Kent Beck from a guy in an orange robe at the L.A. airport.
Some of the main tenets of XP are simple, common-sense ideas practiced to extremes:
- Keep it simple.
- Code in small iterations and fast release cycles.
- Design as you go, with no big, up-front design.
- Put unit and functional testing at the core of the project goal posts, not as an optional add-on.
- Work directly with the customer and/or the user and make them a part of the programming team.
- Make the entire development team owners of the entire project; don’t portion out code to individual experts.
- Refactor, that is, rewrite and improve code, constantly.
- Sleep well, lead a balanced healthy lifestyle except for required eating of junk food for team spirit, and remember, it’s a jungle out there, so always program in pairs.
One Head is Better than Two
Pair programming, where ALL production code is written with two programmers sharing one computer, is the most controversial of all the ideas put forth in XP. While it does lessen the chances of producing poor code, it doesn’t seem to make sense that two competent, experienced programmers working together could produce the same amount of code as they could working separately. To this XPers say, it may be counter-intuitive (and XPers love to say that things are counter-intuitive), but just try it and you’ll see.
Other mitigating factors for pair programming are the often different physical locations for people on the same project, different work schedules, and the fact that many programmers are just ornery, anti-social prima donnas, which iss why they are programmers in the first place. To all this, the peers say, “Try it, you’ll like it.”
Pair programming promotes overlapping knowledge of the application. You are no longer held hostage by a sociopathic?albeit talented?developer who is singularly aware of how a particular part of the code works. And pair programming builds constant communication and feedback directly into the development process.
Pair programming also spotlights XP at its most dogmatic. Certainly, extremely (no pun intended) good code can be written by individuals. Many creative or just plain competent people prefer to work alone and produce good results. But XP says there is no room for a solo programmer. There is an inflexibility to XP that does not account for different personality types and work styles, which may alienate valuable members of your staff.
Design and Code in Small Iterations
In his book, Beck makes some admissions that you don’t often hear from software developers:
- Writing code is hard.
- Many software projects fail.
XP attempts to address all these pitfalls. If a project is doomed to fail, you need to find out fast before large sums of money are wasted. Instead of spending time creating an all-encompassing design and sending the programmers off for six months to implement it, design and code in small iterations and deliver the simplest thing that could possibly work.
XP also espouses constant integration of new code into development versions of an application. It advocates small, frequent production releases for customers and end users. Because of this, customers and users also take a more active role in an XP project. With small, frequent design iterations, customers are constantly involved in the design process. XP advocates having a person in the role of the end user on the project team. It also encourages real-world feedback by getting a project into production with real end users as quickly as possible.
Sometimes XP takes the myopic view that everybody finds software as fascinating as developers. Many end users don’t want their applications to look and work differently each time they use them and would not favor frequent small releases. Most people are not interested in using beta versions of software and may, in fact, get an irreversible bad impression.
Some people might argue that if your design is changing too much for an up-front specification, your project is already in trouble. While technology may be changing rapidly, it’s not changing significantly every three weeks. Also, there is a tremendous overhead (can you say “meetings”?) in perpetually tweaking the design of an application. XPers rebut that experience shows that applications rarely look like their initial specifications, and those that do lack flexibility. If you are sailing to India, you need to lay out a general course. But you can’t possibly anticipate all the changes in currents and winds along the way, so don’t bother trying. XP says don’t commit until you absolutely have to.
XP vs. OOP
XP says don’t design and code for reuse until reuse is needed. Don’t spend money for something until you need it and until you know just what you really need. This goes against one of the holy grails of object oriented programming (OOP), but it is a reflection of how things work in the real world. This is in line with XP’s basic philosophy of simplicity: Do the simplest thing that works; and don’t design or code for possible future requirements.
Another sacred cow of OOP is the ability to delegate responsibility to an isolated modular object or API, and hence, the ability to delegate work to an isolated, modular, cubby-holed programmer. In XP, however, not only are programmers required to work in pairs, they are required to eat in groups, sleep well, develop basic social skills, and, one would assume, bathe. In addition, all team members are free to mess with others’ code. While individual areas of expertise may be thinner, groups no longer find themselves overly dependent on any one individual.
Then there is bad code. Bad, untested, overly complex, buggy, inefficient, unformatted code. Code written by “the other guy.” In the world of XP, tests are written before functional code is written, code is written in pairs, and anyone on the development team is free to refactor and/or rewrite anybody else’s code. So there is no longer an “other guy” and, as a result, no bad code. One can only hope.
Refactoring and Testing
If XP ultimately goes the way of the Pet Rock, one aspect that is sure to stick is refactoring. Refactoring refers to a group of codified techniques used to identify and improve bad code written by the other guy and occasionally by the programmers themselves (programmers will always be referred to in the plural in the world of pair programming). It relies on unit tests to maintain confidence that the refactoring has not broken something else and small incremental changes.
In the first example in his book, “Refactoring: Improving the Design of Existing Code” (Addison Wesley Longman, 1999), Martin Fowler decomposes one “smelly” method in one class into a total of 10 methods spread over seven classes. He goes so far as to bad-mouth comments in code, one of the first rules of Programming 101. While refactoring makes a lot of sense, so did comments, designing for reuse, and separate modular programming just a few months ago. It makes me wonder if we’ll be reading “Defactoring” in a few years with an example of how to combine everything back into one method.
While XP is quite specific about unit testing of code at the method and class level, it is a bit vague about other testing. It does require (XP doesn’t recommend anything) a tester on the project. XP advocates functional testing by customers and/or users to make sure new releases produce the same answers, but it does so with far less zeal than unit testing. XP also gives short shrift to GUI testing, stress testing, and testing in multiple platforms. These can be difficult, time-consuming activities and are often difficult to automate. These tests can also create a large overhead in an environment that advocates frequent releases. But most managers recognize these are high-risk areas that can make or break a software project.
All or Nothing
So why in the world is there such hysteria over something so seemingly sedate as a development methodology (see Egroups.com), and from where is it coming? The answer to the second question may give us the answer to the first: It’s coming from developers. Programmers who are burned out by heroic efforts to save poorly managed projects, isolated in cubicles where they are fed gruel through a slot in the modular wall, then castigated for not satisfying customers they never see. Programmers in the new dotconomy who have seen the balance of labor power tilt in their direction, and now see themselves as inmates with the chance to run the institution.
For project managers, deciding to use Extreme Programming on your next project may in fact feel like bungee jumping off a bridge with a laptop. As a manager, you must be confident enough to give up a large amount of control. You no longer get to say: “I want these features by this date completed by this staff. Make it so.” But convincing upper management that two programmers working together on one task can produce more than two programmers working separately will be difficult.
XP does not cost anything in and of itself, but you must be prepared to make some up-front investments in your project. You have to recognize that quality means more than writing with different colored markers at meetings. It means taking the time to write test cases and refactor code whenever necessary.
The temptation is to pick and choose the features you like about XP?to use the short release cycles, for instance, but not pair programming. To this, XPers give a vociferous “No way, dude.” It’s all the way or not at all.
At first and perhaps even second blush, XP seems dogmatic and fanatical. It espouses lifestyle changes and attitude adjustments and elicits strong responses from its proponents. It demands rigid conformance to all its principles. It would be a mistake to dismiss XP for those reasons. XP is grounded in the hard realities and pitfalls of software development and offers many common-sense solutions. It may not be the final word in the evolution of software development methodology, but it is certainly a big step in the right direction.
