Tuesday, January 05, 2010

What's wrong with Enterprise Customers

I've been thinking about Tim Bray's recent article on what's wrong with enterprise software development. Tim compares the world of agile, iterative, rapid Web 2.0 development to the slow, document-heavy, front-end weighted world of enterprise software. The examples he gives are things like FaceBook, Twitter and a host of other Web 2.0 applications could never have been created if their authors tried to follow an enterprise model.

I couldn't agree more.

However, I don't think the problem is with the enterprise software development groups. These people, by and large, know that the process they are following doesn't work. They're not stupid. So why do they keep doing it?

I blame the customers.

I work for a company that makes enterprise software, and we do our very best to be agile, iterative, and light-weight in our processes. In general we are quite successful. However, we have one massive handicap that no amount of process can seem to overcome. Unlike Web 2.0 products, where customers begin using the product right away and give you valuable feedback as you go along, our customers tell us everything they want up-front and aren't usually interested in seeing the product until it is "done". With customers like that, the successes of Web 2.0 simply cannot be replicated.

Personally, I don't think we need to re-train the software development community. I think they're more than willing to adopt the techniques that have made Web 2.0 successful.

I think we need to retrain enterprise customers. They need to learn the value of working with iterative software. They need to be willing to use things that are partially incomplete, and work with developers to complete them.

Until enterprise customers change their approach and expectations around software, no amount of fancy process or evangelizing of enterprise developers will help.

Perhaps the biggest question isn't "what's wrong with enterprise software development?" but rather, "what's wrong with enterprise software customers?" If we can fix that problem, I predict that the massive successes of Web 2.0 projects and techniques will be mirrored to explosive affect inside the enterprise.


Yaztromo said...

It's not really fair to compare the "winners" of one model with the "losers" of another, to make the claim that one is better than the other. Waterfall can work, and has worked very successfully for a variety of large projects long before Agile came about.

It's also a bit disingenious to compare what amounts to free services to paid-for software. When you become a new user of a free service, your expectations are typically quite low: if it works you stick with it, if not, you leave it. How many Agile, Web 2.0 social network projects akin to Twitter and Facebook projects litter the wayside of development over the last ten years? More than I care to count. And how many of those iterative changes serve only to annoy a large number of (generally powerless) customers? Just look at what happens every time Facebook releases a new iteration that causes even a minor UI change -- some segment of the user population gets into an uproar over it.

A large enterprise paying customer that is investing thousands or millions of dollars into a software project has different expectations. They don't always want to weather bugs, half-implemented features, and constant feature churn. And nor should they have to. An enlightened customer will understand that it's in their long-term best interest to be involved in the iterative cycle, but in an age of quarterly profit reporting, it can be hard to justify having enlightened ideals that incur a quantifiable cost, but that may only pay off years down the road.


Cliff McCollum said...

Yaztromo, I don't entirely disagree with you. You are correct that the Web 2.0 world is littered with failed products that nobody wanted. But I'd bet that there are far less failed PROJECTS in the Web 2.0 world than in the Enterprise world.

My major point is that enterprise customers demand that developers follow a process that rarely achieves success. If we could get the enterprise itself to accept an agile way to iterating towards a solution, we would see far more successful enterprise projects (and products).

I agree that a company spending million of dollars on a software product wants it to be successful. My thesis is that the insistence on delivering a 100% complete product in Big-Bang fashion at project end (typical waterfall) is virtually assured to be incompatible with the primary goal of success.

Software developers have figured this out. Many other engineering disciplines have figured this out. But enterprise software customers don't seem to have figured this out yet.