October 3, 2006

...Learn TDD with Codemanship

Don't Sweat The Small Stuff

When I was a boy, grown-ups were always telling me that I hadn't a care in the world. It's definitely true that as we grow older we tend to take on more and more responsibilities. A bank account. An overdraft. A job. A car. A mortgage. Credit cards. Children of our own one day - though, thankfully, not yet in my case. (I mean, where would I put them?)

When I was 11 years old I had none of these things to worry about. And yet I did worry. I worried quite a lot. I worried about wearing nerdy shoes and getting made fun of at school. I worried about Doctor Who changing from Tom Baker to Peter Davison. I worried about missing Star Wars on TV. I worried about looking foolish in my swimming trunks. I worried that my hair was too short. Or too long. Or neither long enough or short enough. I worried about my Latin homework that I'd left until the morning it was due, as usual. I worried that I might not see that girl in the 6th form that day. I worried that I would see that girl in the 6th form and make a complete idiot of myself. I worried that my sweater was too tight. I worried that my headache might be one of those brain tumours I read about. In short, and despite having none of the responsibilities of adulthood to weigh me down, I worried a lot. Most kids apparantly do. It's normal for an 11-year-old to sweat the small stuff, as the saying goes.

Today at thirty cough-cough years old, I worry a heck of a lot less than I did at 25, and at 25 I worried a lot less than I did at 15. This is in spite of the fact that my life has never been so complicated and risk-prone. How can this be?

Well, at my age I have the benefit of experience, and this gives me perspective. The older I get, the more in-perspective things become. Today I care not a jot if people think the shoes I'm wearing are uncool, or if my sweater is too tight (and, at my age, either of these is more likely to be true). I like to think that I'm better at judging value and at assessing risk. I spend little time fretting about those things that an 11-year-old might be obsessed with, because I can see in the grander scheme that these worries come to nought.

And putting things in perspective is a valuable skill for requirements analysis. How can we know the relative value of feature X without understanding where feature X sits in the grander scheme of things? I've witnessed teams getting totally hung up on the tiniest, most inconsequential details while crtitical matters completely passed them by. I've seen systems go live with glaring holes in their functionality because nobody had taken a step back and asked "what will this be used for?"

If we were having our dream house built for us, we might get hung up on having a room precisely 16 ft x 12 ft, only to discover after it's been finished that - even though the table fits - it's too small to actually play snooker in. What we should have asked the architect for was a "room for playing snooker in", but we specified our requirements at too detailed a level and lost sight of the bigger picture.

This is extremely common in software projects; indeed, in all kinds of projects. The trick is to step back and examine the context in which the software will be used. The stronger a grip you can get on the business processes that surround the software, the better the perspective you can gain on the relative value of requirements. The quickest and most effective way of achieving this kind of perspective is to see it for yourself. If the software is going to be used in a warehouse, go down to the shop floor and watch what people currently do. Take a video camera with you and capture it all in glorious technoicolour for others to see. If it's allowed, try executing some of the processes yourself, to get a true first-hand perspective on things. Whenever I've done this on a project, the mists have cleared and suddenly I've seen what I'm building in a new light. Inevitably afterwards my priorities have changed as I build a better understanding of what really matters. One of the key questions is: what business problem are we trying to solve here, and how does this feature fit into that solution?

In a variation of the Agile Governance game, one of the key skills is identifying potential value. In this variation, the teams forecast value based on a simple probability x points scheme. In real life, estimating potential value is much harder, but perspective shortens the odds considerably. Prioritise on the wrong things, and your chances of success are massively reduced. I therefore believe that this is a key role of a requirements analyst - a proper one, and not just the kind of project ballast I referred to in a previous post.

Estimating value is tough. Usually the relationship between requirements is complex and it's impossible to precisely determine the value of each one in isolation. If we're unable to answer the question "how much is this feature worth?" directly, then we can at least step back, look at the wider context, and ask "how big a deal would it be if we didn't deliver this feature?" We must learn to take a holistic view of requirements, and this is best served by putting things into their correct context.
Posted 14 years, 10 months ago on October 3, 2006