What I've learned from Extreme Programming

October 9, 2006 · Chris Peters

An examination of Extreme Programming, its pros and cons.

Extreme Programming

I’ll admit it. I’ve got a crush on 37signals. I know I’m not the only one, which makes the desire burn hotter. Recently, the company published an entry about the ins and outs of their operations. I decided to check out their link to Extreme Programming (often referred to as XP), a methodology that 37signals obviously borrows some of its process from.

An agile programming framework

I’ve seen much success with iteration-oriented development. Extreme Programming adopts this style. I like that, so XP has earned more of my attention.

To date, one of the projects I’ve been most proud of has been a bid opportunities management system for Franklin County’s Purchasing Department. This was the first project where I tried breaking the tasks into iterations. I planned 3 iterations that spanned over a period of about 6 months. (I was not dedicated entirely to the project, so some of the iterations went longer than most processes prescribe.) I produced a production-ready system at the end of each iteration, fully QA tested.

What did this do for both my team and the customer? Over the next several months that followed completion of the product, we only had to spend about three hours total on maintenance. The system was relatively complex, but due to diligent testing and breaking the project into smaller tasks, it runs rock solid. I truly am proud of it.

Other tidbits that I like

I like that XP looks after the programmer and encourages mentorship and collaboration. I’d like to see it in practice, but it recommends that programmers are always working together on the same code. It also encourages that all programmers be involved with all parts of the system. No embarrassing and stressful code reviews. No worry about losing important application knowledge when someone quits his or her job. No overtime.

I like that XP encourages programmers to get used to doing things that they think are hard. The more you do challenging tasks, the more experience you get at doing those tasks. As a result, programmers learn and become more skilled.

And finally, the methodology discourages unneeded meetings. Amen.

Human Factors is still an art

Like all other development methodologies, XP ignores usability and human factors. But it is called Extreme Programming. I admire that XP’s creators kept the scope focused, but I worry that we will have yet another large army of programmers that ignore user-centered development. Don’t consider this methodology a silver bullet for great product development.

Although it is aimed at small development teams, I’d consider XP best suited for a team of all-star programmers like those employed by 37signals. These guys are interested in product development for human consumption, but they are also very talented at programming. It’s not so easy to find people that understand all of these facets.

About Chris Peters

With over 20 years of experience, I help plan, execute, and optimize digital experiences.

Leave a comment