Thread by @GeePawHill

we spoke of two questions in the recent re-visiting of the money premise. 1) how/why does TDD make changing layered branching logic faster? 2) what's the capital outlay to change to it? i'll stall a little further on 2, but let's do 1.

some provisos before we get started, and they're pretty important.

proviso #1: we are speaking here of a particular kind of test applied at a particular time during development, specifically, microtests applied right before (and sometimes right after) the code that makes them pass.

not every test is a microtest. if u need more info about what they are, ask me or check the site, there's tons of material there. as for the timing, we work *roughly* one microtest followed by one snippet that passes it. there's jiggle there, but that's the target experience.

proviso #2: a practitioner will have to learn how to do this, will have to practice it, and will have to take progressively larger tasks on in this way. it is not a one-paragraph-teaches all kind of thing. (thus the capital outlay).

there are smilin' faces -- to allude to a surprising lyric in a well-known song from my youth -- that will wish so hard for it to be otherwise, they will tell people TDD is easy to get good at. it is not. it's a whole approach, not a "this one weird trick" kinda thing.

proviso #3: it is especially hard to learn how to do it in a TDD-unfriendly codebase. note: it's only a little harder to do it there, once you know how, but learning how is a good deal more difficult in that setting.

if you're gonna start TDD in a massive j2ee or an already-deployed rails app, that's fine. you can do that. but you are going to want to find expert help to start learning how.

so, with those provisos in mind...

i have made the claim that microtested TDD lets you change layered branching logic more quickly than not doing TDD.

how?

i'm gonna sketch the answers pretty quickly here. myself and others have far lengthier explanations of these. ask if you want some of mine.

1) microtests let you write and forget. every geek has had the experience of getting A to work, then implementing B, then implementing C, then discovering that A is now broken. with microtests, A will never break *quietly*.

this makes you faster, because it reduces the number of things you have to hold in your head at one time. it reduces your mental bandwidth requirement for making changes.

(attacking this mental bandwidth is a hallmark of the TDD approach. we've discussed at some length what we know about how much humans can hold in their focus at one time, and it's terribly small. when we push the bandwidth, we don't gradually degrade, we drop like a stone.)

2) microtests provide a second *executable* layer of description on top of the code itself. when you are using TDD'd code instead of writing it in the instant, the microtests provide powerful working examples of how the code was intended to be used.

this lets us go faster because we spend less time in detailed reading of code that is *not* in our current focus. microtests are typically far more revealing than comments or javadoc. faster handling of strange code means more time to work on our focused code.

3) TDD strongly encourages and supports us breaking our design into very modest pieces, and especially into very *modular* pieces. all that theory we read about modularity? TDD tests naturally demand that. writing with TDD is like having an "elements of style" guide all the time.

this makes us faster in a strange & indirect way. because the TDD approach makes some design smells more immediately unpleasant to TDD, we tend to move to better design naturally. we can still write bad designs, but the TDD makes it more annoying to do so. result: we do it less.

real-world analogy: most drivers, with very little thought, quietly swerve around half-wide speed bumps. they *could* go over them, they're not barriers. but they don't, cuz they're just that little bit of push one needs to swerve.

4) TDD makes us faster because it matches amount of effort more closely to complexity of defect. TDD's microtests are almost like syntax-directed editors: they tell you right away you did something dumb, and very little expense.

non-TDD approaches cost you the same amount for a defect whether it's a rocket-science multi-threading race condition that only happens on Thursdays or dumb-assed off-by-one error. TDD charges you less to find latter than the former.

(and ya know what? grow up. the overwhelming majority of the shipping defects in your house are not rocket-science multi-threading thurday-only race conditions. they're one-liner typos-that-aren't-syntax-errors. that snark is going out to my embedded friends with love.)

5) a TDD'er reads, writes, runs, and debugs microtests without invoking the app. no server. no database. no browser. no supporting threads. no container. no upstream microservices. just little bundles of code in a separate app meant for that purpose.

this makes us go faster because c'mon do i really have to explain this? i watch people in web-to-database houses especially, all day long, launch 5 apps to see what their change did. or 4, cuz they forgot one. or wait, did they remember that one? idunno, let's bounce it again.

6) skilled TDD'ers write assertions that say *exactly* what needs asserting. they don't use a human to read a log or even stdout.

well, i'm talking reduction, not elimination. we *all* use stdout sometimes. we go faster because we're letting a computer do what it's best at, and freeing the human to do more of what she's best at. fewer cycles on human-parsing output means more cycles on producing change.

believe it or not, there's more. but i am going to stop right there.

now, for the doubters, i need you to understand where this text is coming from. THIS IS NOT AN ATTEMPT TO PROVE MY CASE. what i am doing with this list is offering you a prima facie case that those of us who use and advocate TDD are not obviously patently insane.

it begs the question, of course, can i? can i prove my case?

well. i certainly can't prove it as efficiently or as compellingly as you can.

if i had my druthers, i'd druther you use these ideas not to convince yourself that TDD does what i say it does, but to let me and others help you actually *try* it and find out.

what i'm after here is to expose you to a snortling experience. you likely don't know that word, cuz i just made it up.

remember the first time you did a cool regex? or maybe a colleague or stack-overflow gave you some unlikely snippet, and u dropped it in and it just worked?

you made a sound -- maybe just in your head -- half-snort, half-chuckle, meaning "well i'll be damned. just like that."

nothing closes a case like a snortle. but i can't get you there until you have a keyboard under your fingers and a problem in front of you. that's what i'm trying to do here.

it's not free, either the experiment or, if it works, the full-on transition. but it's affordable, and when the ducks are lined up, you even start getting the return very quickly.

but it's not free. in the next muse, we'll tackle the capital outlay. how much is this gonna cost?

and for my friends who don't like reading threads, here's the blog: "How TDD Makes Change Faster" geepawhill.org/how-tdd-makes-…