Ensuring your own destruction

When practicing Test Driven Development (TDD) that middle ‘D’ is way more important than the ‘T.’ Even if you don’t write test cases before implementation code, or don’t write formal test code at all, driving the design of your application with the goal of having your code be easily testable forces components to be decoupled, dependancies to be explicit, and functions to be small and focused.

It hurt me to read the post linked below. I could put a shameful checkmark next to most of the anti-patterns listed. I take comfort in the fact that you can’t really learn to avoid these problems until you have experienced, first hand, the extrordinary pain they can cause.

How To Write Untestable Code
http://googletesting.blogspot.com/2008/07/how-to-write-3v1l-untestable-code.html

Whacking the gopher

I was reading up on Cucumber, and came across a link to this article on requirements management. I can say, with confidence, that in the 8 years I have been writing code for money, not once has a project gotten into trouble because of a piece of technology. One hundred percent of the time it was some form of communication failure that threw a monkey in the wrench.

Before the holidays I dropped this bit of science on my coworkers which was met with a resounding "whatever, dude." Regardless, I think (T|B|D)DD amounts to a developer focused solution to the well known problem of dysfunctional communication in software development. Specs, in the rspec sense of the word, are communication. Pound for pound, a spec that is written in plain language, but is also executable, is the best form of software project communication possible.

Fully spec-ing the project is good not just for the internal team or the bosses or the customers. It is often forgotten that one of the most import people that a developer must establish clear communication with is him or herself in the future. 

Now go write a spec.