A site I was browsing (I think it was Slashdot) linked me to a blog with a massive post entitled “Good Agile, Bad Agile”. The author (Steve Yegge) works for Google — and how cool is that — and he’s writing about some of the good experiences he’s had with Agile programming techniques, which he freely admits he normally condemned.
Now, despite the fact that I’ve never been a full-time employee at a software development house, I do have a fair amount of software development experience. Most of it came at United Technologies Research Center. For those who don’t know, that’s the parent company of Pratt & Whitney Aircraft engines, Otis elevators, Carrier air conditioners, and lots more. In short, their an engineering company, and software is done only to enable other activities, rather than as an end unto itself. Bottom line is, most people there don’t have a clue about software; they’re much more interested in the engineering or control models they’re building.
Since I left the company in 2000, I’ve been mostly involved in teaching software development training classes, first for a training company and now as an independent. Every once in a while I’ll get called upon to talk about the process of developing software. The last time was at a chapter meeting of our local PMI (project management institute) group.
As an aside, my experience suggests that PMP professionals (those bold individuals who pay Rita Mulcahy big bucks for her certification book and then survive the exam) don’t understand the difference between managing regular projects and managing software projects. For a PMP, a project is like building a house or arranging a conference. There are lots of details and interacting parties, many resources that need to be coordinated, risks to be identified and plans to be formulated, and so on. The thing is, though, it’s not like nobody’s ever built a house before. It’s not like people don’t arrange conferences all the time. The issue for them is more one of efficiency and effectiveness, rather than whether the project is even possible in the first place.
That’s software, of course. We never build the same thing twice. I suppose as a consultant I could go from company to company doing the same basic job over and over. To choose a current example with lots of buzz words, maybe I could help companies convert their existing systems to web services as part of an overall Service Oriented Architecture running on an Enterprise Service Bus, even incorporating WebSphere Portal Server as part of the project.
(Pardon me for a moment; I just got vaguely nauseous. Too many buzzwords in one sentence. There, I’m better now.)
Even with a general category, though, every company is different, every system is different, every project is different, and in software the differences can be so vast that it feels like you’re starting over every time.
The agile community, especially the Extreme Programming (XP) community, has always had a great appeal to me. That’s because their approach feels like the way I develop software, which, I must admit, is more like having the code congeal rather than being designed. I’m never quite sure what the code is going to look like until I’ve written it, and XP sees that as a good thing, as long as you build lots of test cases around it that you run all the time.
In this particular article, however, one of the comments that jumped out at me is the author’s derisive attitude about paired programming. Since this blog entry is already getting long, let me just say a word or two about that and leave the rest for later.
The principle behind paired programming isn’t really what Mr. Yegge claims. I’m sure he has much more experience than I do and he’s been wildly successful at it, or he wouldn’t work for Google in the first place. On the other hand, one thing that immediately emerges from his blog is that he’s also a lot more cynical than I am, and that’s saying something.
Anyway, paired programming isn’t just adding more people to a development project, but since only two chairs fit at a computer, we’ll just do it two at a time. The idea is that while one person is coding, the other is thinking about test cases, or the overall architecture, or just being an “audio debugger”. Then they switch.
When I was a the research center, I was once involved in a project that was extremely late (shocking, I know, but there it is). There were half a dozen people on the team, but only two of us were doing the actual coding. I vaguely recall that we were putting a TCL/TK interface on an engineering system, which meant Java and Fortran on the back end.
(Hint: Never do that.)
I knew Java and Fortran and some of the engineering details, and the other guy knew the requirements inside and out and how to deal with the TCL/TK stuff. To our astonishment, our manager did not cancel the project when the money ran out and we hadn’t delivered anything. Instead, he essentially locked us in an office and told us to work together for a week and only come out when we were finished.
Here’s the scary part: that week was probably one of the most productive of my entire life. We made decisions, prototyped them, abandoned bad approaches, redesigned the software and ultimately created something that was marginally acceptable but miles ahead of what we had when we started. We did what would later be called paired programming at its finest. I couldn’t believe how productive we were once we got past the initial start up efforts. I also don’t ever remember being that tired after work.
The upshot is, I happen to believe in paired programming, but not totally. I don’t think I could maintain that kind of intensity on a daily basis, nor do I believe I could be productive paired with just anybody. It couldn’t just be thrown together on a daily basis and watch the magic happen.
I wish I could say that from that point on my coworker and I worked together on a regular basis and became absolute stars, but such was not to be. Instead I wound up on a horrible CORBA project in C++ with four project managers that never agreed on anything, but that’s another story, not to mention a series of ugly nightmares.
I think I’ll comment here periodically about the software development process, but the short answer is to check out the explanation of agile development in Martin Fowler’s UML Distilled book and follow up with the rest of his essays. As anyone can tell you, he totally rocks.
Leave a Reply