Test Driven Development is only a piece of the puzzle

The way I talk about TDD, you’d think it’d cure all ills, beget world peace and generally make everything better.

Eh, no.

It makes a few pains better, like if you’re working on a software project or your business is around delivering software on a deadline, it’s going to help you deliver your project on time, on budget, and give you the ability to respond to customer change, faster and with more confidence that you won’t break something.

It buys you peace of mind that you wouldn’t have otherwise. If your software team practices TDD, they will be able to make changes more rapidly and more confidently.

But it’s not an overnight transformation, and it’s only a piece of the puzzle.

The easiest piece to talk about next is your build and integration pipeline. If you don’t practice continuous integration (or at least have automated builds), you won’t be able to respond as quickly when the tests tell you something’s wrong.

If you don’t use TDD from the beginning of your project, you’ll have architectural considerations to worry about: parts of the system that weren’t built to be tested and therefore need help to be able to test them and ensure they’re doing what they’re supposed to.

Likewise, TDD doesn’t solve architecture at a system level; it makes the insides easier to change quickly, but it says nothing about your interfaces to the outside world — like that legacy billing system your system needs to integrate with.

If people are working in one-person silos and you don’t see the value of pairing to increase knowledge transfer and lessen the blindspots, then you’ll get less value out of TDD than you otherwise might have.

If programmers try to mold TDD to their thinking, rather than allow TDD to bend how they think about the problem, they won’t see as much value.

If blind-faith is put into TDD and the system is not evaluated as a whole, as a living organism that responds to external stimuli (office politics, deadlines, budgets, developer skill, designer skill, architectural skill, customer crankiness), then you won’t get as much value out of TDD (the word is “systems thinking”, but I like to think of software as an actual sentient being as it better explains some of the weirdness that happens in software).

If TDD becomes an end unto itself, if it is not pursued because it’ll help the customer, then you won’t get as much value out of it.

My point to all this is: TDD is a piece of the puzzle, and to really unlock its potential, you have to view it that way, and to see what pieces it touches and make sure they’re ready for what’s next.

I’m putting together a video-based online course that will explore these topics while teaching TDD for .NET based software project teams. I believe there’s value in a course that expands beyond the rote mechanics of TDD and embraces how it’s used in the real world to solve real problems. If that sort of thing is up your alley, sign up to receive course updates, occasional emails about TDD, a special subscriber’s only discount that no one else will receive.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.