A few weeks ago I watched Ian Cooper's talk titled "Test Driven Design (TDD) - Where Did it All Go Wrong?" In it, he suggests being more like a duct tape programmer (first time round). It sounded great, so I decided to try it and hit a snag almost immediately...

Duct Tape Programmer

A "duct tape programmer" is someone who throws code together quickly without burdening themselves with code structure, good design, etc. Ian says that management loves them, because they can write working code and ship it to customers quickly. However, they leave ugly and hard to maintain code in their wake, which their colleagues don't like. Plus, they get all the credit due to delivering working software fast, and make the rest of the developers look like slow snails. 

Red-Green-Refactor

Ian suggests writing code like duct tape programmers, and then refactoring later. In TDD it looks as follows:

  1. Red - Write a little test that doesn't work
  2. Green - Write quick-n-dirty code that makes the test pass, committing whatever developer sins necessary in the process (i.e., write like a duct tape programmer)
  3. Refactor - Now that you know how to implement the feature, refactor the code to be well-designed (i.e., now do it properly)

The basic idea is to get something working quickly. Once you've done that then you can use the knowledge gained to "do it properly." The end result is quality code written in less time. It sounds very logical. Well worth trying...

Not So Easy

So, I tried following the process (minus writing the test for added speed). But, as I was hard-coding Javascript includes into templates and cutting other corners, I kept on thinking of better ways of writing the code. A widget base-class that injects Javascript dependencies would be much more elegant, ensuring that the code is only included on pages where it's actually needed.

I simply couldn't let go of the better ideas that were popping into my head. My justification is that I'd use them when refactoring later, so doing it now would save time. So, that's what I did.

To be clear, I'm not talking about grandiose software frameworks or using the latest trendy tool. All of the "better ways" were relatively simple. But, they did take longer to implement than "quick-n-dirty" would have, and I have yet to get to a first working version.

Your Thoughts?

I'm interested in what other developers are doing. Have you tried Ian Cooper's red-green-refactor process? How did it go? Got a better way to balance quick-n-dirty versus thinking through the design? Let us know in the comments below.

The Original Talk

For your convenience, here's Ian's talk: