Steve Vinoski on Extreme Programming at Iona

Thursday at StreamBase we had a lunch talk by Steve Vinoski, Chief Engineer at Iona Software. Our CEO (Barry Morris) is former CEO of Iona, and he asked Steve to talk to use about Extreme Programming (XP). Iona switched to the extreme programming model nearly 10 years ago, and was the first large product company to change over. Their experiences were documented in a paper by Jim Watson.
At StreamBase we use several agile development techniques, but are not faithful to any one methodology. I expected the talk to be about how being faithful to XP was a great thing for Iona. From my reading, I understood that XP demanded total fidelity in order to succeed. Every one of their twelve points is supposed to be critically interdependent and synergistic.
What I learned from Vinoski was that drinking the koolaid is not required. Iona worked directly with Kent Beck, originator of XP. Apparently in person he is a lot more laid back than in his writing. For example, Iona didn’t find pair programming particularly worthwhile, and ended up giving their engineers back their private spaces. They never implemented a 40 hour work week. They do test first programming, but not religiously. They try to fit development into 2 week iterations, but again are not strictly attatched to it. For example, documentation work generally lags behind development, and frequently their iterations don’t actually result in customer-visible functionality.
The other thing I found interesting was that Iona was another example of a pattern I see in extreme programming success stories. At Iona, engineering was a mess before they switched to XP. They didn’t have nightly builds, good testing, or a consistent view of the source tree. Releases were made in an ad-hoc manner, and there was little or no visibilty or feedback in the engineering process. With the introduction of XP they were able to get many of these issues under control. Like many XP stories, things started out really bad. With the introduction of XP they got much better. I can see two plausible explanations for the frequency of this story. It may be that only companies in a lot of pain are able to marshall the resources to change to XP, and so only troubled companies try it. But it may also be that XP is only worth attempting if your organization is on the rocks. Otherwise, moving to a more moderated agile process may be the way to go.
At StreamBase we use many agile techniques. We benefit greatly from automated testing, and have good test coverage. We use a branch driven development model, and keep trunk in a shippable state. We break projects into small milestones (a few weeks, and we keep making them smaller) so that development can be visible. We keep developers as close to customers as possible. And we remain introspective, looking for other opportunities to improve on our process. Many innovations in software engineering come under the banner of agile development today. I think any engineering organization can benefit from learning more about extreme programming and other agile methologies. But I think taking a moderate approach is prudent, unless your organization is in a great deal of pain.

1 Comment »

  1. Another thing to consider when evaluating whether or not XP really is an improvement is that it’s common for people to improve whenever you change their standard process. For example, in the early 1900’s, when manufacturers first introduced assembly lines, workers got excited at the chance to learn a new technique, and productivity skyrocketed. After a while the new-ness wore off and productivity started falling again. (Sorry I don’t have a cite for this, but I’ve come across it in places like harvard business review, and the history channel).nnIn other words, there’s a placebo effect for any process change — even bad ones.