30 Jan, 2008

Commentary on The Art of Agile Development's The XP Team sub-chapter.

I replaced the windows in my house last year. My wife and I bought a 1939 home that needed some work. It's livable, except for one problem: the windows were coated with lead paint, and we had a newborn baby girl. Plus, they leaked cold air like a sieve. So we had to replace the windows. We knew that when we bought the place.

Windows are a big purchase. The windows we replaced had been there for nearly seventy years. I hope the ones we put in last at least as long. They're also quite expensive. So naturally, I put a lot of effort into finding a good vendor. I was looking for two things: a good price, and quality work. If I had to choose just one, given how long we expect to stay in this house, I would have chosen quality over price.

I certainly wouldn't have shopped around for the cheapest possible price I could find. Sure, I could have gotten different windows for several thousand dollars cheaper... but they would have looked it. The ones we got have nice sculptured grids (to mimic the look of the originals), smooth action, and come apart for easy cleaning. If we had cut corners, I would have noticed (and regretted it) for the next twenty years.

When you're buying something expensive and valuable that's meant to last a long time, you put real effort into it. So why is that so many companies treat software development like buying disposable tupperware? Why do they look for every opportunity to minimize cost? Sure, you can do that, but TANSTAAFL. There ain't no such thing as a free lunch. Cheap software development leads to cheap software. It's buggy, it doesn't do what you want, and it's expensive to maintain.

I particularly see this attitude when it comes to staffing teams with business experts. Sometimes the problem is with programmers--they focus on saving pennies, while sacrificing dollars. "Our business experts have better things to do," they say, not realizing that they're putting a multimillion dollar investment at risk. Other times, it's the business experts who hide, finding ways to make themselves unavailable.

It's so bad that I sometimes wonder if XP's demand for on-site customers is its achilles heel. And then I remember that you can use XP without on-site customers, just as you can use other forms of software development without involving users or business experts. You're just less likely to succeed... in either case.

When I look back at the teams I've worked with, the teams that took software seriously--the ones that saw custom software as a strategic asset, not something to cost-cut into oblivion--had no problems putting good, competent people in the customer role. They brought in high quality people, people who knew their stuff backwards and forwards, and those people had their hands full figuring out how to make the software shine. It wasn't always easy--one company flew one of their domain experts in from London on a regular basis--but they knew that good results require good investment.

Keep an eye on those companies. Software runs everything. They're the ones that will succeed.