The Fallacy of Test -Driven- Development

A couple of years back I wrote a short piece titled
"http://www.yafla.com/dennisforbes/Edit-and-Continue-Valuable-Tool-or-Sloppy-Vice-/Edit-and-Continue-Valuable-Tool-or-Sloppy-Vice-.html">Edit
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
process.

Today I came across DevGrind’s "http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/">How not
to solve a Sudoku
entry – itself linking to Ravi Mohan’s
"http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html">Leaning
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 "http://www.yafla.com/dennisforbes/To-GUID-or-not-to-GUID-In-Your-Databases/To-GUID-or-not-to-GUID-In-Your-Databases.html">
To GUID or not to GUID in your Database
, where I describe the
benefits and pratfalls of GUIDs in the database.