This is a transcript I excerpted from a discussion session video that I just watched where Bob Martin addressed the Chicago ALT.NET user group where he is describing the rationale behind TDD in the context of understanding how truly brittle our work products really are.

This is a short read, but everyone is encouraged to think long and hard about its ramifications for our ability to produce work with confidence…

Software is a remarkably sensitive discipline.  If you reach into a base of code and you change one bit you can crash the software.  Go into the memory and twiddle one bit at random and very likely you will elicit some form of crash.  Very, very few systems are that sensitive.  You could go out to one of these bridges over here, start taking bolts out and they probably wouldn’t fall.  I could pull out a gun and start shooting randomly and I probably wouldn’t kill too many people.  I might wound a few but — you know — you get a bullet in the leg or a lung and you’d probably survive.  People are resilient — they can survive the loss of a leg and so forth.  Bridges are resilient — they survive the loss of components.  But software isn’t resilient at all: one bit changes and — BANG! — it crashes.  Very few disciplines are that sensitive.

But there is one other [discipline] that is, and that’s Accounting.  The right mistake at exactly the right time on the right spreadsheet — that one-digit error can crash the company and send the offenders off to jail.  How do accountants deal with that sensitivity?  Well, they have disciplines.  And one of the primary disciplines is dual-entry bookkeeping.  Everything is said twice.  Every transaction is entered two times — once on the credit side and once on the debit side.  Those two transactions follow separate mathematical pathways until they end up at this wonderful subtraction on the balance sheet that has to yield to zero.

This is what test-driven development is: dual-entry bookkeeping.  Everything is said twice — once on the test side and once on the production code side and everything runs in an execution that yields either a green bar or a red bar just like the zero on the balance sheet.  It seems like that’s a good practice for us: to [acknowledge and] manage these sensitivities of our discipline…

-Robert C. Martin

Just more food-for-thought in a never-ending stream of consciousness…I see this as yet another great analogy to reflect back to those who remain unconvinced of the rationale behind TDD as a core practice — it seems to me that the question to be asked is really “if you don’t plan to manage this sensitivity through the practice of TDD, how do you propose to manage it –?”  Its not clear to me that the TDD-naysayers have an alternative short of ‘cross our fingers and hope’.

For both the entire Q&A session as well as the whole talk at the user group meeting, follow the links above and happy viewing~!