Two Paths: Repetition or “Feel” ?

The pain in Test Driven Development (TDD) comes from developing software the same way you did before you found TDD.

That sounds like an odd statement to make, I know, but from my experience it’s on the mark.

Or, by way of analogies:

If you play golf, you’ll get that one of the hardest parts of the game is the ‘short game’. That part less than 100 yards from the pin, where finesse and control win over sheer power. You can get to the pin in 100 yards — the question is, can you get there accurately and repeatably.

Dave Pelz came up with a repeatable method for getting to the pin accurately. It’s called the ‘clock system’. Basically you practice with each short-game club and you hit 100 balls at 7:30, 9:00, 10:30 for each club, until you’ve dialed in the exact distance using the exact same swing each time. No ‘feel’, just raw numbers and repetition. Once you know how far each club goes at each clock position, you write those three numbers on a piece of paper and tape it to the shaft (this is permissible under USGA rules). And voila, you can go to any course, anywhere and as long as you know your distance from the pin, you’ll be able to get there, accurately.

This is a highly valuable system if you play golf regularly; but it represents a fundamental change in how you practice and play golf. You can’t go back to ‘feel’ after learning this method — it would be at cross purposes if you did (I tried to and it was super weird and I gave up ‘feel’ entirely).

TDD is the same way. Once you internalize that TDD represents a fundamental shift in how you solve problems, it’s difficult to go back. You can do it — sure,but once you do you’ll see those painful things you avoided by using TDD.

if you’re interested in an online course that teaches you and your team how to build complex software using TDD, sign up at course.doubleyourproductivity.io

If you want a more personal touch, or have a project where you’re not sure if TDD would be a good fit, reach out and let’s chat.

Leave a Reply