We were five years into a startup that was going nowhere, lost in the first wave of dotcom craziness. We’d grown from zero to three hundred people in a couple of years then endured massive turnover for the next three years. We must’ve burned through a thousand people and a hundred million dollars. It was madness.

Then the layoffs started.

After the second round of layoffs, my boss challenged me to come up with something to help with the sagging morale of the engineering organization and encouraged me to put together a team to build a skunkworks project that I’d been working on. We’d have carte blanche to work however we wanted to work. As long as what we came up with was scalable to the whole team eventually, we wouldn’t have to follow our normal software development lifecycle which was something like this:

1. Spend a week writing a functional spec without talking to anyone.
2. Take another week to copy-paste the functional spec and change a few words so we could call it a technical spec.
3. Give the specs to the QA folks then code like hell for a month. The QA folks didn’t read anything yet because they were still finding bugs in the previous release that would never be fixed.
4. Feature complete! Stop coding!
5. Declare that you are 90% done with just a few edge cases left to fix until…
6. Code Freeze!
7. Carry on coding until the last possible moment and answer questions from the QA folks and the writers about why the finished product looked nothing like the specs.
8. Fix the bugs in a maintenance release.

We’d been doing this three times a year for five years and that odd mixture of High Ceremony and Minimal Discipline was wearing on the soul.

We called our experiment Project X and commandeered a conference room for our kick-off meeting. Julio suggested we try Extreme Programming. “What’s that?” we all asked blankly.

We bought ten copies of Kent’s new book and all agreed to read it over the weekend. I had never been so excited about a book on software methodology. We were all excited.

Extreme Programming (XP) puts an emphasis on collaboration so we all moved out of our cubicles and commandeered a meeting room so we could work together. In XP, programmers work in pairs with a single keyboard that gets passed backwards and forwards between them. We switched pairs every couple of hours. With everyone talking to each other all the time, there was no need to write everything down in specs that no one would read anyway.

Programmers were notorious for hating testing and, in those days, nobody wrote automated tests. XP introduced a new style of testing. You write the test before the code which guarantees that your code has 100% test coverage.

We did a demo of test-first programming to the whole engineering team and invited someone in the audience to introduce a random bug in the code. There were audible gasps from the audience when the tests found the bug immediately (*).

(*) At that time, our main codebase had 1000s of bugs in our bug database.

Planning was different too. Instead of the product managers going off into a room for two months and producing a massive requirements document, the programmers would sit down with the product managers for a couple of hours and write everything that needed to be done on a bunch of index cards. We called them story cards because they told a story about how the user would experience the feature rather than making a list of tasks for the programmer to complete. Put the cards in order of priority and decide whether each story is big, medium or small and you have a plan. If you change your mind later, you can always tear a card up or change the order.

This was another big change from the before-times. Back then, we’d have a detailed plan saying it would take 7.5 hours to code the buttons for the chart options and if someone wanted to move the buttons to a dialog, they’d have to submit a change request and then the project would be replanned and someone would negotiate whether a chart dialog was more important than printed reports. With XP planning, you just start at the first card and work your way down the list. When it feels like you’ve done enough, you call it finished and ship it. There’s no big testing phase at the end because everything gets tested as you go along.

The Project X team loved XP and most of us still love it twenty years later but everyone else hated it.

“How can we plan anything unless we lock ourselves in a room for a month without talking to anyone?”
“No wonder you enjoy it when you only have to do half the work!”
“We have to test our own code? Don’t we pay other people to test our code?”

Eventually, Project X came to an end and we went back to our bad old ways. We could take responsibility for how we wrote and tested our code but everything else stayed more or less the same. We hired new dudes to do more planning and eventually, we found ourselves trapped in The Planning Cycle That Would Never End. Finally, the Layoff Monster came back and I asked if he would take me with him.

I got my next two jobs on the back of my knowledge of test-first programming and iterative planning but no one was interested in Extreme Programming. Most managers thought of it as a kind of cult.

Maybe we were a kind of cult. Kent had shown us the best way to write code and no one was interested. For a long time, I got terribly depressed that we had discovered this brilliant way of building software and no one cared but, in hindsight, I think XP had an incredible impact on the world of software even if everyone thought that XP was nuts.

The way we build software now is very different from the way we built it back in the old days. The projects I work on now have two or three bugs instead of two or three thousand. Developers write automated tests. Instead of tracking bugs, we fix them and we write a test to make sure they stay fixed. QA people are no longer in a different part of the building, forbidden to talk to developers. We have conversations instead of writing specs and if the requirements change, we change the code instead of filing a Change Request Form. No one thinks of these things as XP anymore but there is a straight line from the first XP project at Chrysler to the Agile Manifesto and modern software practives.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile Manifesto, 2001

I shudder when I think back to how we used to build software. Although Extreme Programming did not stick, Kent Beck changed the way we write code forever and his book, Extreme Programming Explained changed my life.

What else changed my life?

Way back in the day, when everyone had a blog, someone started a meme where you had to list ten books that changed your life. Rather than just list them, I thought I’d tell a story about each one. It’s going more slowly than I thought.

Here are the previous four. I’ve lost my list of the remaining five but I remember it included Cialdini’s Influence, Russell’s History of Western Civilisation, The Collected Works of Byron and a book about playing the harmonica. Maybe I’ll finish it one day.