Ats Goes Extreme

First, a bit of background. I'm a consultant, and I was brought in to this company (they've given me permission to discuss ATS here, but I don't know if they want their name mentioned) -- I was brought in to this company to build a line-of-business application in Java. It had to use servlets and Oracle on the back end to connect to a Java applet on the front end. The primary purpose of the application was to allow company employees to track projects involving company customers. To support this primary role, the application needed a minimalistic contact management system as well.

There were a total of four of us on the project, all contractors. One of the programmers mentioned ExtremeProgramming to me, but I didn't know anything about it, so I decided to base the project on PeterCoad's FeatureDrivenDevelopment methodology instead. FeatureDrivenDevelopment is characterized by three-week iterations, low ceremony, and heavy emphasis on delivering and tracking UserValuedFeatures?. My success with this methodology, along with some things that I intuitively practiced (in particular, CollectiveCodeOwnership, YouArentGonnaNeedIt, and Refactoring), opened my mind to the concepts of ExtremeProgramming. I have to admit, I was originally turned off by the name and wouldn't have given it a second thought if I hadn't been bored one evening, looked at one of the Extreme websites, and seen practices that I had already discovered to be useful. PairProgramming also did a good job of sucking me in, since it was so counterintuitive to me... I had to find out more to see how it could possibly be defended.

As I mentioned, ATS development went very smoothly. At least, it did on the technical side of things. Two weeks before we were scheduled to deliver our first release, at the end of the fourth iteration, the project was abruptly cancelled. Someone had made a mistake in calculating the budget -- we were over budget, there was no more money, now would everybody go home, please? I was able to wangle one more week to do a knowledge transfer with an in-house developer who had sat in on our design meetings and code reviews, and who had helped a lot with database design. Together, we backed up to the previous iteration's deliverable, which had all the features the users had identified as most important, and deployed it. Then that was it. Everybody went on to other things, and ATS was over.

Or so I thought. Six weeks later, I received a call from my consulting agency. Would I be interested in resuming work on ATS? I was between jobs at the time, and had really enjoyed my experience at the company, so I readily agreed. None of the original team was still available, but the employee I had trained was, and two more consultants were hired. It turned out that the original budget calculations had been wrong (!) and that there was much, much more money available than they thought. So they wanted us to finish up ATS and put security in place. Although the users had originally identified security as being very low priority, it turned out that most people had very good reasons that they couldn't use it unless there was security, so they needed us to implement that piece.

(FeatureDrivenDevelopment does include an initial phase where the users get together and prioritize all of the FeatureSets? that have been identified. Security was put at the very end of the list. I think this was because we misidentified the primary user of ATS. The actual primary user had his own application that he had built himself -- it wasn't perfect, but it would keep him happy until we got to security. I had identified budget problems as a risk, but a low one, and I don't think anybody actually thought that was a possibility. The user who we misidentified as the primary user never got his group to use ATS, and was eventually moved off of the group entirely for unrelated reasons. So in the six weeks since the security-less version of ATS was deployed, it's seen no real use. In retrospect, security should have been much higher on the priority list... maybe even one of the first things implemented.)

In the six weeks between the end of the first phase of ATS and the beginning of the second, I did a lot of research into ExtremeProgramming. The more I learned, the more I was intrigued by it. On my personal projects and a few small commercial ones, I experimented with UserStories, UnitTests, PairProgramming, and YouArentGonnaNeedIt and Refactoring taken to the extreme. All these experiments turned out very well, and I became determined to use ExtremeProgramming in my next project.

When the invitation to resume work on ATS came along, it was the perfect opportunity. I had been concerned about trying to explain the radical nature of extreme programming to a skeptical customer, particularly without extensive experience in using it to point to. ATS, though, had been a very successful project technically, and I had gained a lot of respect at that company. As a result, I'm trusted to choose the right technique to get the job done, so I don't have to do a lot of stammering and blushing while I try to explain why I'm using a methodology whose name sounds like it was born from a surfer's hangover. ("Whoa... dude... you're a programmer? That's, like, extreme, man! Yeah, you're an extreme programmer, dude. Heh heh.")

And that's how the stage was set for ATS to go Extreme. I describe how it turned out in the AtsDiary.

-- JimLittle

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006