Noel Rappin Writes Here

While I’m commemorating anniversaries this summer, I just remembered another one.

Ten years ago this summer was when I first read the original Kent Beck “white book”, Extreme Programming Explained, which is one of only a couple of books that completely changed the way I approach whatever it is that I do. Considering that I’ve spent most of the last ten years practicing, advocating for, and writing about XP and Agile development, it’s not an overstatement to say that Kent’s book, and the ideas about how to be a professional programmer, changed my professional life.

Here’s the setup.

I spent most of the winter, spring, and early summer of 2000 working on a largish web project for a Fortune 500 company that you’ve definitely heard of, but which made a regular practice of scaring the hell out of any vendors who might want to ever advertise the fact of their association.

This company was large enough to have a technical conference/fair for the IT departments of its various subsidiaries. I remember attending as a vendor, and being in a presentation from the company’s legal department that prominently featured the comment, “you vendors have the silly idea that your liability is limited to the size of your contract with us”.

Anyway… the project was a collaboration among several subsidiaries that had never worked together before. Not only was this the largest project I had been on by far, but there were also about a half dozen customer companies that all had different ideas about how the project should run – it wasn’t unusual to have conference calls with about three dozen client representatives to about five of us. I always kind of thought that the reason our tiny web company was picked for the project was to act as an impartial referee.

Unsurprisingly, we made every mistake there was. We picked tools that were not adequate to the task, and although our application design wasn’t bad, regressions were a constant feature of our staging deployments. The customer kept changing the goals of the site, not to mention tiny details, and we had no way to organize or manage the changes. We had an ongoing argument with one of the internal teams who wanted us to change our entire database schema. Our own management grabbed half the development team to completely redo the interface less than a week before the deadline.

We did deliver on time, but only after my one-and-only real death march to date, over a month of 70-80 hour weeks. (At which point the customer froze the site and didn’t deploy, but only looked at it internally for two weeks. Never did learn why.)

In the wake of the initial delivery, my company did some retrospective sessions. I had heard about XP a little at that point, and was looking for some way to vocalize my feeling that the project had been a structural failure, even though we had more or less delivered on time. Which is how I came to read the book in the first place.

Unsurprisingly, XP’s emphasis on sustainability, clear descriptions of priority and responsibility, testing, refactoring, and quality code resonated with me pretty strongly. It seemed like a rebuttal to every pain point we had in the project. I remember reading directly from the book at a retrospective meeting, prompting some wisecrack from a manager about my academic bookishness. Guilty, I guess.

With one thing and another, it was several years before I was in a position to impose a full Agile/XP project structure on a project. Until then, what I was able to do was test – even in places where that wasn’t part of the team’s normal process. The fact that test-first seemed so helpful made the whole Agile structure seem more plausible, and when I was finally able to put an Agile project in place, I was ready to make all new mistakes.