June 1, 2007

...Learn TDD with Codemanship

Should We Expose IT Follies?

I'm an annoying little sod - well, not so little, actually - most of the time.

One of the really annoying things I like to do on IT projects is ask questions like "why will this 15th version succeed where the previous 14 failed?"

Usually, when I look at requirements specifications, I have to admit that I'm clueless as to what value it might bring to my clients. I just don't get it.

And for a long time I thought it must be because I'm a bit thick, and there actually is a proper business plan behind the project, but I'm just too dense or naive to see it.

More recently, after spending more of my time working at the higher levels of management as a consultant, and after watching many episodes of Dragons' Den and The Apprentice (I mean, who could ask for a more comprehensive business education?), I'm less convinced that there's a bigger picture that I'm not seeing.

In fact, I think that many IT projects are very misguided. And many very senior business leaders are, in fact, just winging it. They seem to know little more than you or I about what makes a business successful.

If they're hired executives, then their actual talent is probably for climbing the greasy pole; great at getting to the top, next to useless when they get there. If they're entrepreneurs then they almost certainly just got lucky.


In business, we're all winging it

And this creates a bit of a professional dilemna. The received wisdom these days is that it's the customer's job to define the value in an IT project. As developers, our job is to realise that value by delivering the features the customer asks for. Fair enough. It's not our business, so why should we be telling them what they should ask us to build?

A good development team knows how to deliver working software. So that's our side of the bargain taken care of. But the sad truth is that the customer is often as completely in the dark about the requirements as we are. It's the blind leading the blind.

Somehow I can't help feeling that - for a consultant, at least - I do have some responsibility for probing and testing the business plan behind the requirements. 9 times out of 10 the logic quickly collapses and the project is exposed as a folly.

They do say* that most projects fail in the board room, and I wonder if our best practice of catching defects as early as possible shouldn't extend all the way back to the executive washroom or the golf course.


* No, they do, though, don't they?

Posted 13 years, 6 months ago on June 1, 2007