On XP: A Humanist's Programming Methodology

The term "eXtreme Programming" is a lousy name for a very good idea, or a set of very good ideas, about how to produce programs. Programming is a difficult task. It's easy to write a line of code that executes properly, but it's hard to craft applications that do everything they're supposed to, work reliably in actual use, and arrive on time and on budget. XP suggests the reasons for this failure are social: they stem from the all-too-human nature of the groups of people who produce applications. Development goes bad when the team loses its focus on the projects' goals, communicates insufficiently, loses morale... all these things allow entropy to take over and pull the project down. The solution to bad development lies in a different social organization for programmers--a different team structure and a different ethos. I would argue that XP's vision for the programming team is a remarkably humanist one: it suggests that Man (or Woman, in this case the programmer) is indeed the measure of all things. XP connects the programmers to each other and to the higher goal, and it enbales them to do better work.

Kent Beck, the godfather of XP, claims that the inspiration for XP came from putting together a plan to tackle a really hairy real-world problem in real-world programming time, i.e. right away. He didn't think it up while lounging around and thinking abstractly about computer programming. He forged it in the trenches of a challenging project. He thought about generally-accepted programming practices, habits or procedures that most developers think help to make for better software: testing, frequent integration, communication with the customer, short development cycles, refactoring, code review. Then, he thought about how to maximize the effect of each practice by, well, taking it to the extreme. Test everything, all the time. Integrate constantly, every time you make a non-trivial addition to the code. Communicate constantly with the customer by having one onsite to review the day's progress. Shorten development cycles to a day, or a few hours, to introduce small units of incremental functionality. Refactor all the time, by assigning refactoring tasks along with new functionality tasks as you go. And, if code review is good, then do it all the time by pairing programmers to each task. Also, trust your team to want to win, to want to succeed for the benefit of all, and send them home at a reasonable hour every day.

XP's critics claim that taking the core practices so far detracts from progress and hurts the team's efforts. You spend too much time writing tests. An onsite customer will drive you crazy by changing his or her mind all the time or not understanding what you're doing. Refactoring will break stuff left and right. And, of course, pair programming is equated with the coming of the antichrist: your team will take twice as long to get things done, your introverted programmers will resent having someone looking over their shoulder, your paired programmers will just goof off together. Finally, it's naive to think you won't be working 60-hour weeks all the time.

I think most critiques of XP reveal a bias in the critic--a deeply ingrained idea that software production is a miserable, brutal, antagonistic affair. There isn't time to do the project the Right Way. The customer is an idiot who doesn't understand his or her business' needs. Your application will be too brittle to handle refactoring, or your programmers will be too stupid to avoid breaking stuff. Your programmers are anti-social (or too social) lazy good-for-nothings who don't want the project to succeed. And let's not even discuss XP's endorsement of the 40-hour work week: we're going to be working overtime all the way through because endless struggle is the only way to muddle through. If I as the project lead don't crack the whip all the time, we'll never make it. This is a deeply pessimistic worldview, and not the attitude I'd want my supervisor or my client to have.

XP, I think, provides hope for developers because its component practices support and encourage the individual's efforts. The promise of testing is, "You will be as sure as you can be that your code is right." The promise of the onsite customer is, "You are developing the right application." The promise of refactoring is, "You will find the Right Way," The promise of pair programming is, "You won't have to go it alone, you will have help." The overall promise of XP is, "You don't have to be afraid."

I like XP personally because it seems to describe programming the way I see programming, as a social activity that should be stimulating and rewarding. It suggests that people learn best from experience and from each other, that a team should share responsibility for a project, and that everyone has something valuable to contribute. I'm a self-taught programmer. With the exception of a few continuing education classes on Java, my knowledge comes from self-guided study and learning-by-doing. The XP team appeals to me because it's the kind of environment in which I thrive. I don't think I'm alone in that preference for social, cooperative work. Some of us are anti-social, but not most of us. Some of us frequently learn things the first time when we read a manual or a textbook, but not most of us. I think most of us would do best in something like an XP environment.

I do at least a few hours of XP every week at the New York City XP Interest Group meetings at Union Square Internet Development, in Chelsea. We meet every Monday and learn by doing: we're currently producing an application that will track changes to the schema of a database and provide summaries of changes between schema versions and DDL for rolling back to a previous version. It's a bit like version control for databases. We're using Ruby, an object-oriented scripting language that I'm learning as I go. I've gained a lot of confidence in XP and in myself at these meetings. If you're in New York and you're interested in XP, you should come by.

More Related Links