January 24, 2007

...Learn TDD with Codemanship

Flip For It

A problem that comes up time and again in both real projects and the simulated mini-projects I run in training workshops is analysis paralysis. For example, I sat back and watched a programming pair debate energetically with each other over which flavour of Model-View-Controller to apply to their Java application.

This went on for about 30 minutes - and this is 30 minutes in a project lasting only 6 hours, mind you - and then I decided I ought to step in (which is a shame, because it was very funny and I was quite enjoying it.) In these kinds of situation you have a deadlock. Both guys genuinely believed their choice of MVC implementation was best. But neither could explain why it was the best.

So we had two choices, and - as far as we could tell - either might turn out to be the better choice. There was only one meaningful way to find out, but in order for that to happen, somebody had to give in and go with the other's choice.

A few years back I started doing something that helped break the deadlock, even if it did ruffle a few feathers. I flipped a coin: Heads for choice A and Tails for choice B. In this case, it came up Tails and they agreed to go with the second choice of MVC implementation, which turned out to be a mistake.

But - and this is the point I'm trying to make here - it was a mistake they had to make to know it was a mistake. The information required to tell us it was a mistake was in the code we wrote. We had to write that code to see why it was a mistake. We took a chance. It could just as easily have been the right choice. No amount of analysis - short of creating an exact model of the code (i.e., the code) - would have forewarned us of the problems.

Most importantly, the bad decision only took 15 minutes to reverse. That's half the time the guys wasted arguing about it. And this is often the way it is with software. Sometimes the only way to know for sure is to suck it and see, and the real cost is in failing to make a timely decision.

Harking back to the well-worn golf analogy, there comes a point where we have to stop taking aim and just hit the ball and hope for the best. Knowing where that point comes is an instinct the most productive software developers tend to have.

And if you don't have a coin - perhaps because, like the Queen, you don't carry cash - here's an online coin tossing facility you can use.

Hours of fun :-)
Posted 14 years, 6 months ago on January 24, 2007