The Fallacy of Test -Driven- Development

A couple of years back I wrote a short piece titled
and Continue – Valuable Tool, or Sloppy Vice?

I pondered whether some development tools and practices
— such as test-driven development (TDD) and
the reduced cost of errors (in both time and
personal reputation) — were actually making us worse
developers, paradoxically decreasing productivity and the
suitability and correctness of solutions.

That entry was motivated by the outpouring of demands by my
peers that a particular tool continue to feature edit-and-continue
functionality: what I thought would be an infrequently used frill
turned out to be something that many depended upon daily,
correcting their flawed code at runtime as a regular part of their

Today I came across DevGrind’s "">How not
to solve a Sudoku
entry — itself linking to Ravi Mohan’s
from Sodoku Solver
” — where he links to a gent who
implemented a thoughtful, sober design carefully, and another who
pursued a TDD-approach, building his test harness, and then, it
appears, flailing about madly in the hopes that some random
keypresses will generate a solution that passes the test.

To demonstrate the value of TDD.

…Today’s blast from the past is "">
To GUID or not to GUID in your Database
, where I describe the
benefits and pratfalls of GUIDs in the database.