Mike Hill writes about how TDD and pair-programming increase production. He hits the nail on the head here:
TDD increases your production because it serves as a thinking-aid. It limits back-tracking and gold-plating and it reduces code-study and debugging. Pairing increases your production for the very same reason. Two developers together don’t type as fast as two developers separately, but we don’t care: the bottleneck is the thinking, and pairing and TDDing both improve it.
Actually, he hits another smaller nail in the beginning of his post:
Sometimes I feel like some of these folks try too hard to soft-sell the excellent way presented by test-driven development (TDD) and pair programming (PP)
It’s true. Meeting with prospects, I usually get asked: "If we start doing unit tests we add X ( X changes every time) amount of work, right?" and I usually answer "It’s actually Y, but you gain…" (you know the rest). And any sentence starting with "but" does not sound that convincing, is it? I am planning to use some of Mike’s arguments, and see how people react.
And while you visit Mike’s blog, "Situated Geekery", look up another good post on "Microtests" (which is basically a good unit test).
