The Fallacy of Test -Driven- Development

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

I pondered whether some development tools and practices– such as test-driven development (TDD) andthe reduced cost of errors (in both time andpersonal reputation) — were actually making us worsedevelopers, paradoxically decreasing productivity and thesuitability and correctness of solutions.

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

Today I came across DevGrind’s How notto solve a Sudoku entry — itself linking to Ravi Mohan’s”Leaningfrom Sodoku Solver” — where he links to a gent whoimplemented a thoughtful, sober design carefully, and another whopursued a TDD-approach, building his test harness, and then, itappears, flailing about madly in the hopes that some randomkeypresses 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 thebenefits and pratfalls of GUIDs in the database.