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.