A client paid me a wonderful compliment the other day. He phoned to ask me for my thoughts on a new feature he's thinking of adding to a software product I designed for the company a while back.

He ploughed on and I listened for a while, and then said: "Ah, yes, that's all very well, but you need to consider how to handle [insert collection of special cases he'd not thought of]".

He laughed, and said: "I love calling you ... you always make me realise stuff isn't as easy as I think it is".

I've worked on enough projects in my umpteen years in IT to know that what they teach you at software development school is right: before you start doing anything, you need to figure out the requirements - and make a proper job of it. And don't think for a moment that being trendy and using "Agile" development methodologies is an excuse to figure things out as you go along, cos it isn't.

I'm working on a project at the moment where changes to the data model would put the project back by days, if not weeks, because there are so many components to change and such a high risk of regression failures. Thankfully the colleague I worked with when we designed the data model is a genius, and I'm a pedantic git who thinks of weird "what if" cases, and in the six months since we designed the model we've not had to tweak it once. The development methodology has been as "Agile" as I've ever known, but because we did out requirements analysis pretty well, we managed to get it right first time. And my goodness, I'm so glad we did.

Find your next job with techworld jobs