time, this morning, to return to the underplayed TDD premise called the money premise. in one phrase: "we're in this for the money."
what does that mean? in the software business, like every other business in a long period of very high demand, we make more money when we ship more value faster.
please be careful here. when we say "more value faster", we're not trying to constrain the possible varieties of value. THIS IS AN INCREDIBLY IMPORTANT THING TO REMEMBER.
there are lots of kinds of value we could ship. we could be talking about more features, more function, more stability, more performance. all of these are values we can ship more of faster with full-on TDD.
i know. sounds like maybe i skipped my meds, right? how on earth can one approach supply more value faster when the values listed above are so different from one another? (it's okay, go ahead and back away slowly. i get that a lot.)
the answer is actually straightforward. it's because TDD is currently our best known answer to the challenge of changing layered branching logic, and all of those values depend ultimately on exactly that: changing layered branching logic.
"making software" *is* "changing layered branching logic". TDD is the fastest way to do it that we currently have. that's all it is. it's not mystical, or ideal, it's not a slogan we can put over a poster with eagles on mountains. it's a style of changing layered branching logic.
you want more money? you get more money by changing layered branching logic faster. the money premise is hard-nosed about this. "we're in this for the money."
when you tell me your managers won't let you TDD because they don't want you to "take the time", either they or you or both are not understanding the proposition correctly.
most commonly, they or you or both think that TDD is some kind of quality initiative. in other words, that the value of TDD depends on us wanting fewer customer-noticed bugs. this is a misunderstanding, and laboring under it is costing your organization *money*.
TDD allows us to change layered branching logic at a significantly faster marginal rate. we don't have to justify paying a higher marginal rate for TDD in terms of one or another of those values, because it doesn't have a higher marginal rate, it has a lower one.
now, don't misunderstand, there's no free lunch, and TDD certainly isn't one. there *is* a startup cost. it's possible that you and your management are arguing about the capital outlay -- the cost of getting us all to a TDD style.
we can argue about what that cost is, and whether we can afford to do it now. that, at least, is a legitimate argument to be having. but let me make this clear: if NON-TDD and TDD both had zero capital outlay, one would never choose NON-TDD for any reason, because TDD is faster.
when you go to management & propose TDD, you absolutely must keep the money premise front and center. "at some initial outlay, we will be able to ship more value faster, for *your* definition of more value, as long as that value depends on us changing layered branching logic."
don't let them get sidetracked on that word "test". that's just a label. TDD has almost nothing inherently to do with the usual uses of that word, all of which are focused around a specific kind of value. you have to make that clear.
TDD lets us change layered branching logic far more quickly. we can use that speed to add more function, to raise the customer perception of our quality, to improve our runtime performance, to do *anything* that depends on changing complex layered branching logic.
the money premise: we're in this for the money. in software, money comes from shipping more value faster. TDD is the fastest current way to do that, regardless of the particular kind of value we need, as long as getting that value means changing layered branching logic.
and for the hard-of-threading, here's the blog: "We're in TDD for the Money". geepawhill.org/we-are-in-tdd-…
