QualityCode.com Essay: Why Extreme Programming?1
This weekend, it finally clicked for me what XP (Extreme Programming) really is, and why I believe in it so strongly, even though I’ve never used all the practices at once on any project2.
Years ago, back around 1988, a friend pointed out to me that it makes sense to develop a very simple, stripped-down version of a program first, and then add to it. That immediately resonated with me based on my experiences up to that time. From then on, I have consciously used “simplicity” as my focus and as a measure of quality.
Most of the successful projects I’ve been involved with over the years have taken that basic approach: Get something simple working, and then add to it. Projects that have taken the BDUF (Big Design Up Front) approach have generally failed—sometimes taking the company down with them; other times just not living up to potential.
Much of my success at my current (non-XP) company has been due to my focus on doing the simplest thing possbible, and avoiding designing for a future that might never arrive. I tried to give the product manager opportunities to change her mind late in the process, knowing that she would be able to get us started earlier if she didn’t feel locked in.
One big part of XP is that you should start simple, get it working, and then add more pieces, one at a time. Now, I realize that this incremental approach is really the heart of XP [IMHO], and that’s one reason I like it so much. But XP also puts an entire framework around that approach that makes it work much better. Simplicity is good. Simplicity combined with all the other XP practices is better.
With XP, you build automated tests into what you build, so you know that it is always doing what you expect. As you build, you also “refactor” the code aggressively, redesigning as needed, rewriting confusing sections, and looking for dead code to remove. You pair program. You work closely with the customer. And so on…
The “successful” products I worked on were never refactored, so after several years of adding features, the code was complex and confusing. You couldn’t rewrite the bad pieces, because you were afraid you might break something (no tests). XP would have prevented those problems.
Conventional wisdom these days says that you can be a more “mature” and successful software development organization through more up- front planning. Think the entire project through before you start coding. Have clear breaks between the analysis, design, and coding phases. This is my current boss’s philosophy.
In my mind, all of this is an attempt to solve the underlying challenges by brute force. XP, on the other hand, acknowleges our inability to fully understand the problem up front, and creates an environment where we expect change, and handle it easily.It allows the project to flow wherever it needs to go to be successful.
The first book on XP was published one year ago. Two more books came out this month. I strongly believe that XP will be quite popular within a few years, because it is better both from a technical, and from a social perspective (it’s friendlier to both programmers and customers).3
I want to do XP now because I want to be on the leading edge of this wave. I want to be one of the first people who realized that this “new” way of developing software will allow many projects to be far more productive than they would be using “conventional” approaches.
No wonder it’s important to me. 4
1 Originally posted to the extremeprogramming mailing list October 22, 2000
2 After writing this essay, I led a very successful project that used about 80% pure XP.
3 I was wrong about XP becoming popular, but was correct that agile development would become mainstream. XP requires far more effort and discipline than Scrum or Kanban, which makes it more of a niche process.
4 Back in 2000, I left one job, and turned down another, because they weren’t going to allow me to experiment with XP and agile methodologies. It was that important.