Thread by @agilecoach

Oh, dang. Now I’m all riled up & can’t focus. Been wanting to go toe-to-toe with <them> in a discussion about #TDD for over a decade. I think I’m going to have to vent. Here. Now.

Ready?

First, the history of my introduction to <them>. We met, at a conference, and they said “Ah! You teach TDD? That stuff is dangerous! If Kent Beck were in Europe, he’d be imprisoned for the damage he’s done!”

Let’s generously assume they were using hyperbole, or really angry about something else, or needing therapy. Assume good intentions.

Still, there is a dimension here that bothers me: People going to prison for promoting an idea? People being responsible when their ideas are misused? (We’ll get to just how badly misused in a moment.)

History part 2: They wrote a two-part article in a trade magazine (when we still wasted paper on such things) on how TDD failed their team, how the developers were psychologically crushed by the failures. I read the whole article. Possibly twice.

And it didn’t make me angry, it made me sad. They talked about how the developers had to write customer-facing tests without input from the business. How those end-to-end tests then had to be implemented, and how that wasn’t any easier.

Where did they get such a messed up impression of how TDD works?

There was, at the time, talk of “Acceptance Test Driven Development” (ATDD), where the team (the WHOLE team) writes story tests before (or while) the story is being implemented. That’s not TDD.

It’s also NOT BDD. Neither TDD nor BDD are “write the tests (plural) first.” Both are one-at-a-time, in rapid succession, with thoughtfulness, dialog, & REFACTORING between each test/spec/scenario.

What they were doing was not TDD at all. They had a bad mix of TDD (developer-facing unit tests) & ATDD (customer-facing business scenarios) concepts. I have no idea why the “Agile coaches” on the team would allow such a misunderstanding to progress. Unless...

The article described their process in detail, called it TDD, then explained what an utter disaster it was. That feels like a Strawman Argument to me. (Maybe there’s another name. Whatever. My point is that it’s patently illogical.)

We did Y, which we thought was X. We failed at Y, ergo X is bad.

We did our research. We got published. Now we are justified in vilifying the person who first suggested X.

Ohhh…I’m getting riled up again.

Now, a tweet or N about my own experience with TDD. I first learnt it from Fred George in 1998 (before it was named TDD, & before the Agile Manifesto). Alas, we built great software for a piece of STK hardware that never saw the light of day. But fortunately...

I got to use TDD in 2001 w/ @jamesshore who is extremely good at tossing out practices, frameworks, & notions that don’t work. I’d say we learned the real value of TDD on that product.

& my next TDD experience in 2002 w/ @menloprez

@jamesshore @menloprez Again in 2003 for a SV startup. 2004 for a different SV startup. ~6 years doing TDD full-time on ~6 very different applications, at least 6 months each.

@jamesshore @menloprez In each case, TDD paid off in three technical ways. (The personal benefits to the team were awesome, too, but there’s a whole book coming up on TDD that will cover those… ;-)

@jamesshore @menloprez 1. The #TDD benefit always touted and most immediately obvious: An immediate reduction in the amount of “oops!”-type defects. The new failing test lets us know we got that little boolean equation correct. Avoids simple logic mistakes that we all make. E.g., > when I meant >=

@jamesshore @menloprez 2. When it’s time to alter the code in some way to accommodate a significant change, the suite of tests allows us to refactor (the design of existing code) quickly & confidently without breaking anything (the behaviors of that existing code).

@jamesshore @menloprez 3. In the long term (IME around the 6 month mark, & roughly once every 6 months), the business will request a significant, unanticipated, radical, & extremely valuable change.

@jamesshore @menloprez No tests, or slow tests (e.g., taking more than an hour to run them ALL)? “Sorry, that would be a major architectural change requiring six months…”

A thorough & fast (20 minutes or less) suite of tests? “We can have that for you in less than two weeks.” Every time.

In summary: Before dismissing TDD as dogmatic, agonizing, or pointless, try doing it right first!

And if you're not sure what that is (or you think I’m using the One True Scottsman argument), just ask me. I’m kinda passionate about it. For me, it made crafting software fun & sane again. For YEARS.

Okay… whew! I feel better. You? :-D

Addendum: I interviewed @menloprez in 2015, & he mentioned that the 2002 product was still being enhanced. He also let me know that no developer had to work an evening or weekend to fix a severe defect since 2004.

@menloprez How can that be?! No critical defect repair OT (on life-critical software) in 13 YEARS? InconCEIVable! Or…TDD.

There you go. There’s one personal benefit. A big one. Imagine, developers: You could go home. See your families…

Happy Holidays!