Seeing the light

I'm no expert on extreme programming, but everything I've seen so far makes it look like something we'd want to do some of.

Another of the lineup of speakers who caught my imagination at the CIO magazine conference the other week was none other than Mr Brian Dollery -- the man who fills this page when I don’t. I went along to Dollery’s presentation primarily because I’ve never met him and I wanted to.

What ended up happening was that the bugger really got my head spinning. Bravely having himself introduced as "a fat, scouse bastard" (all of which is true, by the way) set the tone for his presentation; his views are interesting, refreshing and, for more than a few in the audience, challenging.

Now, I’ve read a few of Dollery’s columns and, while I’ve found them informative and enjoyable, the idea of XP (extreme progamming) has never really ripped my nightie. This is mainly because the idea of doing in-house development requiring programming of any flavour -- extreme or otherwise -- has, over the past couple of years, become less and less palatable to me. Don’t get me wrong -- I did my time as a developer and we (that is to say, my employer) have had some fantastic mileage out of developing at home in the past, and I can’t see a day when we won’t be doing some tinkering. But my goal over the last couple of years has been for my organisation to get closer and be more responsive to the business it serves. The last thing we need is to go tying up lots of resource in major (read: lengthy and costly) development projects.

Buying off-the-shelf products and using my people to manage getting them in and making them work well seems like a far better idea. The generally held industry view is that buying typically costs only 40% of what developing does. It’s perceived as being lower risk because the hard work’s already been done and someone else owns, documents and maintains the code (and the bugs). Sounds ideal. There are some compromises involved too, of course. You often have to buy more functionality than you actually want. Sometimes it goes the other way and there are functionality gaps or you have to make the business fit the software rather than the other way around. But, overall, when you consider the reduced cost and risk, buying rather than building is definitely the go.

What, though, if there was another way? What if there was a development approach that reduced cost and risk? I’m no expert on XP -- I’m still doing the reading and learning about this thing -- but everything I’ve seen so far makes it look like something we’d want to do some of. I don’t think I’m about to throw caution to the wind and hire a bunch more programmers and become a full-on development shop again. But I’m definitely into using some XP techniques to make the "tinkering" we do (and with maybe doing a bit more tinkering than we currently do) add as much value as it can. This, with my shallow understanding, is the basic tenet of XP: adding value. It’s all about low risk, quality, quick turnarounds and doing the 20% of the work that solves the 80% of the problem. This is development for the real world.

Cheers Brian, thanks to you I’m feeling wide awake to some new possibilities. Oh, and I’ll be reading all of your columns from now on, too.

Swanson is IT manager at W Stevenson & Sons in South Auckland. Send letters for publication to Computerworld Letters.

Join the newsletter!

Error: Please check your email address.

Tags extreme programming

Show Comments
[]