The parallels between double entry bookkeeping and Test Driven Development are deep and plentiful.

• Both are disciplines used by experts who carefully manipulate complex documents full of arcane symbols that must, under pain of terrible consequences, be absolutely correct in both type and position.

• Both involve representing a long sequence of granular gestures in two different forms on two different documents.

• Both techniques update their documents one granular gesture at a time, and each such update concludes with a check to be sure that the two documents remain in balance with each other.

To put this in more concrete terms:

• Accountants enter each transaction into two different accounts. One is a Liability account. The other is an Asset or Equity account. These accounts are summed on the balance sheet, and the following relationship must hold: Assets + Equities = Liabilities.
• Accountants are trained to enter transaction one at a time, checking the balance sheet after each such entry.
• Programmers who practice TDD enter each new granule of behavior in two different programs. One is a test program. The other is the desired production program. The two must execute in a complimentary fashion demonstrating that the production code works as the tests describe.
• Programmers are trained to add one granule at a time to each program, and then to execute the tests after each such addition.

As I said, the equivalence between the two disciplines is stark. They are virtually identical approaches.

And no wonder. Both disciplines serve the same purpose. Both allow those of us who maintain complex documents full of arcane symbols that must be absolutely correct under pain of severe consequences, to be confident that those consequences will not be encountered.

Do accountants have deadlines? Do managers put pressure on them to finish their accounting by a certain date? Of course! There’s no difference in the pressure. Accountants feel the pressure just the same as programmers do.

Are the programs of the programmers somehow less important than the accounts of the accountants? Of course not! Those programs are the instruments that make or save the company money. They are critically important. They are easily as important as the accountants’ accounts.

So then why are accountants able to maintain their discipline so assiduously and so completely? Can you imagine a group of accountants saying to each other: “Guys, we’re really under the gun. We’ve got to finish these accounts by Friday. So, do all the Assets and Equities. We’ll come back and do the Liabilities later.”

No. You can’t imagine that. Or, at least, you shouldn’t. Accountants can go to jail for doing things like that.

So then why is it that so many programmers wail and moan when confronted with the discipline of TDD? Why do they present so many reasons why TDD is impractical, or unreasonable, or…

Can you imagine an accountant making excuses like these: (All taken from articles about TDD)

• I never do double entry bookkeeping because keeping track of all those accounts takes too much time.
• Accounts don’t need to be prefect, they only need to be good enough. Double entry bookkeeping is overkill.
• All these accountants who practice double entry bookkeeping are just too religious about it. They’re following an unnecessary dogma.
• Balancing the Assets and Equities with the Liabilities doesn’t actually prove that the accounts are correct. So double entry bookkeeping is too much work for too little benefit.
• Double entry bookkeeping is a scam promoted by consultants who are just trying to make money by selling books and courses and videos.
• Double entry bookkeeping is dead. The guys at Andersen consulting wrote a blog about it.
• I am against double entry because experience shows that it prevents high quality account design from emerging.
• I thought double entry was an elaborate practical joke when I first heard of it. It’s monumentally dumb.
• Double entry doesn’t work. I don’t care what you’ve heard. I don’t care how much your manager wants it. I don’t care how much the stress-spattered eyes of your coworkers gleam in their endorsement. It. Doesn’t. Work.
• Double entry promotes account design damage.
• Not everything is accountable.
• Double entry locks the account design.
• Double entry sounds good in theory. But, in practice, it’s not clear how good it is.
• Life is short and there are only a finite number of hours in a day. So we have to make choices about how we spend our time. If we spend it by making double entries that is time we are not doing something else.
• Using double entry does not guarantee that you’ll design good accounts.
• I’m going to go out on a limb here and declare with brutal honesty that it’s literally a ritualistic waste of time.
• Another concern is the debated degree of perfection to which one must do double entry to do it successfully. Some insist that if double entry isn’t done persistently by everyone on the team from the beginning of the project, you’ll only suffer.
• Double entry rides on guilt. It encourages procedure over understanding. It has tons of doctrines and slogans.
• For me, the double entry zealots are religious loonies knocking on my door, trying to prove that my way of doing things is irreparably broken and the only path to salvation is double entry.
• What annoys me about double entry is the fact that there are a lot of rules or guidelines about it.
• On your first double entry project there are two big losses, time and personal freedom.

I could go on. (And on. And on.) You will find that there is no lack of silly, misinformed, and disgruntled detractors.

The bottom line, for me, is simple. TDD is a good discipline for ensuring that the complex documents, full of arcane symbols, are crafted in such a way so as to avoid significant negative consequences. I know of no other discipline that comes close.

Double entry bookkeeping was invented by the Koreans over a thousand years ago. It was independently reinvented by the Italians over six hundred years ago. It flourished and spread along with the capitalism and economic prosperity that it helped to secure. However it’s adoption was not without resistance and delays. The last countries to standardize on double entry bookkeeping did so in the twentieth century.

Let’s hope it doesn’t take 500 years for a discipline of testing to becomes the standard for software developers.