May 31, 2007

...Learn TDD with Codemanship

Take Your Time If You Want To Go Faster

It's nice to work with smart people.

Smart people get the jist of things just that much quicker, and it can make all the difference.

Yesterday I got round the whiteboard with a couple of smart people and we did a dry run of a proposed specification technique - a combination of test-driven development and storyboarding to see how it might pan out for their organisation.

There are all sorts of traps and pitfalls lurking in those kinds of sessions. Less sharp individuals, for example, might simply fail to "get" the technique, and we all know how common it is when things go wrong for bad workmen to blame their tools. (The mythical "use cases killed our project" headline!)

No such worries here. Whether they choose to use it or not, they certainly got the hang of it. At least the learning curve is one less obstacle I need to worry about.

And while they were sketching out the storyboard, detailing - with sufficient precision and clarity - how the UI would look at each step in the scenario, I made a mental note of how many decisions got made jointly between the developers and the "customer" and how many times we might have avoided a misunderstanding (and roughly how big a deal it might have been to resolve those misunderstandings by reworking code).

We spent about 45 minutes talking things through, and in that time we may have saved ourselves many hours of unnecessary - that is - avoidable rework.

To the untrained eye, this process looks very laborious and, frankly, a bit anal. I wasn't all surprised when we took our handiwork and showed it to senior managers that their first instinctive reaction was to exclaim: "But if we did this for every scenario, it would take us forever!"

It looks like we're going slow, but countless industry studies across thousands of projects, plus my own personal experience, makes it clear to me that teams who put more effort into quality assurance in requirements analysis tend to do less work overall.

Taking care up-front makes us go faster. To a point.

I'm going to use another bloody golf analogy here:

What tends to happen on most projects is that, under schedule pressure, managers stand over us with big sticks and shout "go faster, go faster!". Let's imagine our project is a round of golf: we planned for 18 holes to take 3 hours, but after 2 hours we've only completed 7. An inexperienced team captain might stand over the players as they take their shots screaming "quickly, quickly!" This is, of course, completely the wrong thing to do. The captain should calmly encourage their players to relax and to take their time over their shots. In golf, the way to get round the course faster is to take more care on each shot.


Golfers go faster by taking more care on their shots

Software development is exactly the same. It's all very well rushing out code, and in the initial stages the illusion of productivity can be very seductive to managers and developers alike. But those of us who've been there, eaten the pizza and got tomato sauce on the t-shirt know only too well that this early spurt will be short-lived. Reworking code is expensive, and a lot of rework happens because we validated decisions after we'd written the code.

We cannot - and should not - try to eliminate all rework, of course. But a good chunk of it is avoidable, and we should seek to eliminate it as mercilessly as we refactor our code. (Which we all do, don't we?)

And, yes - you can take it too far. Just like a golfer can take too much care over their shot. There's a point beyond which taking more time and care on requirements probably won't help us to avoid significantly more rework, just as there's a point where taking more care over a golf swing probably won't get the ball any closer to the hole. This is why golfers practice putting, and developers practice refactoring (because we do, though, don't we?)

And before anybody out there thinks: "Yes, perfection is the enemy of good enough", bear in mind that I've yet to come across a team who got anywhere near going too far, in either up-front QA or refactoring (though I've seen plenty of teams get stuck in analysis paralysis, which is a completely different kind of problem, and is often mistaken for "taking quality assurance too far"). You can pull the quality lever much harder than you think. Pull it 'til it hurts, then pull it some more.

And when it's a client-facing activity, like storyboarding scenarios and writing acceptance tests, it can hurt quite a lot. This is where you need courage and discipline. Resist your manager's, your customer's and your team's pleas to "go faster". You must be firm. It's for their own good, and - months from now - the results will speak for themselves.

Oh, and don't forget to clear your desk on the way out...
Posted 13 years, 6 months ago on May 31, 2007