The Woodsman, the Smith, and the Ax

A woodsman walked into a smithy and said, "There's a problem with my ax."

"What's wrong?" asked the blacksmith.

"I think it needs to be sharpened. I can't seem to chop down any trees with it."

My Pre-TDD Years

When I was initially exposed to test-driven development's precursor, test-first programming, I immediately sensed the value.

Yet I didn't take the leap, right away. It required a change in my mindset and in my habits. Those things were hard and thus deferred. So years passed with me saying to myself "I really should write the tests for this, first".

What broke me out of the rut was when a test engineer said "I really love your code."

Adopting the TDD Mindset by Altering Habits

Previously, I wrote that test-driven development is a mindset, more than it is a skill. It's easy to learn but it's difficult to adopt because you have to change how you see and think about software development.

One way to modify your worldview is to form an habit and allow that habit to gradually transform your perspective. That's exactly how I made my transition to being a test-driven developer.

How TDD Can Help with Design

Test-driven development can help you with your software design.

People who make this claim sometimes emphasize the fact that good designs tend to be easy to test. This mislays the active force and makes a very simple process sound almost magical.

The important factor is not that good designs are easy to test. It's that bad designs are hard to test.

Test-Driven Development as a Mindset

For what I consider to be a long time, I've been trying to help people adopt test-driven development. It always seems more challenging than it should be.

I think I might finally have identified the fundamental impediment: I'm trying to teach people something that cannot be taught, because it is not really a skill.