A couple of years back I wrote a short piece titled "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 How not to solve a Sudoku entry -- itself linking to Ravi Mohan's "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 To GUID or not to GUID in your Database, where I describe the benefits and pratfalls of GUIDs in the database.