[Note: This is a repost of an entry I wrote for my company blog at http://www.intunity.com.au/2012/06/25/applying-tdd-to-guitar-amps/]
Here at Intunity we have a really big focus on quality. Making
robust software that is flexible enough to meet clients ever changing
needs (in a short amount of time) is hard. That’s why we have all those
TLA‘s
floating around and other Agile terms that make non Agile practitioners
wonder why we’re talking about Rugby all the time. However once good
engineering principles soak in you find that you tend to start applying
those principles to other areas of your life. For myself it was
applying TDD
to another problem – I thought my guitar amp had broken.
Understandably that made me a really cranky product owner and I wanted
it fixed yesterday!
If you don’t know how guitar amps work, there’s a few major
sections. There’s the input, the pre-amp, the effects loop, the
power-amp and finally the cab (speakers). They’re all connected in the
order listed. Like hunting for a bug in a multi layered application I
could have dived in and started randomly probing (or breaking out the
soldering iron), but just as in software I would have probably wasted a
lot of time. So I “wrote a test”. I plugged in my trusty electric,
tapped my line out jack (the signal is the same that is fed into the
power-amp) and played something that I knew would expose the problem.
The result – it’s all good.
I didn’t take it as a failure though as I’d halved my search area all
with one test and ~1 minute of time. Now the power-amp is a dangerous
section (if you’re not careful you can get electrocuted) so before I put
my affairs in order, I ran another test by plugging the amp into cab
and repeating the same input. The problem remanifested itself.
Jiggling the cable around to test for (and eliminate) a dodgy cable, I
found that the cable was loose in cab socket. Opened the back of the
cab and bent one of the metal contacts back so that it touched the cable
better and problem was fixed – with no electrocution risk.
All up 3 tests and 10 minutes.
To be honest the story’s pretty boring (unless you’re a guitar gear
nerd) but it highlights the value of TDD in that it changes how you
think about problems (and solve them). By testing you’re understanding
(or defining) your system. You’re learning about the problem domain and
setting up conditions so that you can prove a problem (if you’re bug
hunting) to then fix it. It’s also pretty obvious when you’re dealing
with a piece of physical equipment that will cost you money if you break
it; that you might want to be careful and not rush in. The result
ironically is that by being “slower” you’re “faster” because you’re
proceeding with knowledge.
One’s software (or client’s software) is the same. By practising TDD
you have less waste, faster code, better understanding and that end
product that all developers crave – a working piece of software.
By applying TDD to a more physical problem it only helped me see the
more of great advantage in the practise. After all I do like saving
time and money and our clients do too :D
