Thread by @searls

Buckle up:

"Why people who are really good at test-driven development (TDD)—even people who write about it, speak on it, and maintain tools to support it—don't always practice it," an exclusive twitter dot com thread in reply to this toot by @RobOldCodes:

https://twitter.com/RobOldCodes/status/1135972854489649152

I was introduced to XP & TDD in 2004, fumbled around with them on-and-off for a while, then in 2009 joined a series of teams that practiced TDD consistently, thoughtfully, and rigorously. No joke, we shipped production apps with 100% code coverage in Java & JavaScript(!) in 2010.

This rigor necessitated all manner of necessary-but-hilarious inventions. Like my Maven plugin that ran browser JavaScript tests on top of Rhino and in an artificial DOM environment. Or that mocking framework I wrote in PL/SQL that ran on Oracle databases.

Things got a bit weird

As a result, my thoughtleader-ey bona fides are rooted in testing (I'm proud to be the top google hit for "tdd failure"). But I'm no dyed-in-the-wool purist claiming there's One True Way to write great software.

You'll have to find your silver bullets on some other Twitter feed.

My lack of zealous fervor disappoints some folks looking for someone to look up to, but I'd encourage them that it shouldn't.

Programming is very difficult, and each of our journeys to mastery is deeply personal. If TDD makes something click: awesome! And if not, that's ok, too!

When @toddkaufman and I founded @testdouble in 2011, my speaking career was picking up steam and it presented a choice: do we sell a prescriptive, slick, branded TDD® Process™ like @pivotallabs was doing, or do we take the harder path and admit that every situation is different?

I have never once regretted our choice to take the harder path. We grew more slowly. Our marketing is not crisp. Our service offering is amorphous.

But it's the truth. And it's attracted a diverse group of colleagues and clients who share a vision that software should be better.

In the end, rigorous TDD practice in multiple languages taught me (and, I suspect, several of my colleagues at @testdouble) three invaluable things that I apply to all my code, whether or not I used TDD. Even if it's not tested at all.

Here's what I learned from a decade of TDD:

1. Understanding feedback loops—the speed and quality with which I can make a computer answer my questions—are my job to design. The program that gives me feedback (e.g. test, REPL, etc.) governs how much I get done in a day. Mastering this is as important as the app code itself.

2. TDD's constraints pushed me to consistently design small units of code; each with a single purpose, organized logically, given a clear name, and with a simple API. If you start to write code this way, you can get a helluva lot else wrong and still manage to recover gracefully.

3. Want to learn something big? Prepare to muscle through a long slog of moving frustratingly slowly. If you try to learn TDD (or vim or Haskell) but retreat when it gets hard, you won't be able to discern whether the practice (or tool) is a poor fit or if you don't "get it" yet.

I learned these three things by deciding to buckle down and practice TDD seriously and in earnestly. But you can absolutely learn them other ways, too.

I try to to share tools & guideposts to help others on that path, but please don't mistake it for advocacy of TDD over anything

Most importantly, if you only take away one thing: never, ever let someone make you feel ashamed because you don't (or don't know how to) make software in some particular way.

Nobody has this all figured out, and anyone that claims to is wrong. Those people deserve more scrutiny

Finally, if you've read this far and you appreciate this kind of open-and-honest embrace of the nuance and trade-offs to improving at software development, you now know why @testdouble exists.

If you'd like more people who approach problems this way on your team, let us know! 💚