Paired Programming works, sometimes

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.

Random thoughts

It’s way too late at night for me to be thinking clearly, but my internal clock still hasn’t quite adjusted from my trip to Amsterdam yet and I’ve got too many thoughts running through my head.

(Plus, I’m too tired to actually do any work on my Hibernate materials and trying not to feel guilty about that.)

  1. Maybe it’s just me, but when I was playing with the Ajax toolkits, all I can hear in the back of my mind is the bad sensei from Karate Kid saying, “Pain … does not exist … in THIS dojo!”  Yeah, that’s probably just me.
  2. Speaking of obscure movie references, one of my all-time favorites is from the horribly overlooked movie Mystery Men.  I just love it when William H. Macy (playing The Shoveler) turns around and says, “We’re on a blind date with destiny — and it looks like she ordered the lobster.”  It’s funny ’cause it’s true.
  3. I was bringing Xander back home from the Hebron Harvest Fair (exactly what it sounds like) when we turned on the Red Sox game.  We heard Jason Varitek hit a home run to cut the deficit against Kansas City to 8 — 5.  How pathetic is it when you need a two-run homer to get within two runs of KC?  Then they rally for even more runs, including Big Papi hitting a double to make it 9 — 8, when we heard the inevitable words — Mike Timlin is warming up in the bullpen.  We were home by then and had the game on NESN-HD.  Sure enough, Timlin blows the save and we lose 10 — 9.  That’s been the story of the Sox’s season since the All-Star break.  I’m trying not to get too depressed about it.
  4. When I was in Amsterdam, I had two Nederlanders and a German in class.  As often happens, a random joke occurred to me.  It involved Rodney Dangerfield, but unfortunately none of the students had ever heard of him.  Wrap your head about that one a minute.  Yikes.  No Back to School references, no Caddyshack references, no nothing.  Talk about getting no respect…
  5. On a related note, I have an instructor friend who grew up without a television.  I have no idea how she teaches.  Without my pop culture references, I feel like I’m teaching with both hands tied behind my back.
  6. I can’t tell whether learning more JavaScript is making me appreciate how cool Ruby is, or if digging into Ruby helps me understand how slick JavaScript can be.  Being able to add properties and functions to an existing library class just by writing code as if they were already there is way cool.  And that’s just the tip of the iceberg.
  7. Speaking of JavaScript, JSON is really interesting if only as an alternative to XML.  While I don’t necessarily subscribe to the massive backlash against XML currently sweeping the industry, parsing XML just isn’t fun.  If, however, the server-side code returns a JSON string representation of your data ([{first : ‘Buffy’, last : ‘Summers’, job : ‘slayer’},{first : ‘Willow’, last : ‘Rosenberg’, job : ‘witch’},…]) then JavaScript automatically gets it and can access it immediately.  That’s so much nicer than walking a DOM tree.
  8. Raw Ajax involves two of my least favorite programming activities: parsing XML by hand, and debugging JavaScript.  Yuck.  Frameworks like prototype and dojo make both so much easier.  Plus, the Firebug plug-in for JavaScript is just sweet.
  9. Which brings me to the book Pragmatic Ajax.  When I first got that book, I wasn’t really all that wild about it.  I liked the approach and some of the recommendations, but it didn’t feel as practical as Foundations of Ajax nor as interesting and profound as Ajax in Action (still my favorite technical book at the moment).  But on the plane to Amsterdam I still couldn’t get the ATF toolkit to install in Eclipse properly, so I spent time reading more and more of that book.  It really gets good as you go along.  I wouldn’t make it my only Ajax book, or even my first Ajax book, but it’s great reading after you already have a feel for the technology.  In addition to the technical content, the authors also tell some great stories, too.  Somebody should tell them about Firebug, though.
  10. I received an email today from somebody who actually reads this blog.  That’s a very strange feeling.  Maybe I can aspire to a “Sports Guy circa 1998 back when he was only the Boston Sports Guy” mojo, where I could develop a small core of loyal, slightly “off” readers and share humorous software-related in-jokes with them.  Or not.

I think that’s more than enough.  It’s late.  Time to go Hibernate (insert groan here).

Ajax Teaching

Ajax in Amsterdam

You know what I hate?  When I feel my phone vibrating on my hip and I’m not wearing my phone.

This is my first time in Amsterdam.  The training site is an IBM center, but I think this is just a room rental.  I’m a sub to a sub to a sub again, so it’s a bit confusing.  It’s also rather surprising that my client’s client felt that it was worth the travel costs to hold a class for only three people.  Works for me, though.

The Ajax materials I’m using this time are very different from the one’s I’ve used before and they’re pretty raw.  Lots of set-up and lab corrections to do, but I think I have most of them worked out now.  It’s very interesting that these materials are strongly focused on Ajax tool kits like Prototype, Dojo, and Rico.  That’s no doubt the future of Ajax.  From a spectator sport point of view, I’ll be watching to see which toolkits win the mindshare wars.

Prototype is definitely going to win, partly because it’s cool ($(), $F(), and all that) and partly because it’s the basis of so many others.  I’m not sure whether Dojo and Rico are going to win out over Scriptaculous, though.  We’ll see.