Thread by @GeePawHill

my five TDD premises stuff has been well-received over the months since i put it out, but one of them seems still very underplayed, even by many died-in-the-wool TDD'ers: the correlation premise.

the correlation premise says that the internal quality of our code correlates directly with our productivity. when the internal quality goes up, productivity goes up. when it goes down, productivity goes down.

all of the premises were formulated in part to undercut dangerous misunderstandings about what TDD is and why we do it, of course, and the correlation premise is that, too.

the misunderstanding: that the quality of the code can be traded for the productivity of the coder, that these two dimensions are orthogonal and antagonistic to each other.

evidence that this misunderstanding is still in play is plentiful. and while i certainly can see how folks new to the made-making-maker triple focus of our movement misunderstand, i'm surprised on a regular basis by "agile advocates" who are still embedding it in their work.

even in casual chatter, shoot-from-the-hip conversations, numerous folks who i think of as inside the movement strongly imply they still are binding themselves to the orthogonal/antagonistic vision of code quality and productivity.

let's work this out again, as simply as possible.

the nature of programming is always this: at time T i have code C, and at time T' i want to make code C' from it, so i make changes to C until it becomes C'.

right? no demurrals yet?

that's what programming is, it's changing some code C to some code C'. it is never not that.

consider a program that prints out the integers from 1 to 10 inclusive. call that code C.

there are myriad ways to do that, but i'll pick two. in codebase C1, we have 10 print statements in a row, each with a constant argument of the correct integer. in codebase C2, we do it with a variable in a for loop. each pass through the loop, we increment the var & print it.

now consider program C', our target program: it has to print out the integers from 1 to 100 inclusive. i want you to think about the difference between changing C1 to do the new C' and changing C2 to do it.

which one do you think will be easier to change?

well. u don't have to write many baby programs before you agree that changing C2 will take less time than changing C1.

both programs implement C. both programs can be changed to implement C'. but one of them is faster to change than the other.

the entire meaning of "internal code quality" is exactly that. ICQ is precisely synonymous with "faster to change".

now. i know that the various things we talk about as ICQ have at least three properties that can make this a difficult step for us as analysts. let's make sure we mention those right now before this thing goes off the rails.

1) there is only modest consensus about what the actual details of ICQ practice are. the trade has nearly unanimous agreement, for instance, that GOTO's are usually negative. no such agreement exists around, say, immutability.

2) the trade's changed even its *consensed-upon* mind, several times over the years. structured programming's single-exit policy, hungarian notation, there are lots of these now-largely-abandoned practices that were once considered fundamental ICQ.

3) horrific "enforcement" projects abound in the trade, simultaneously pushing both well-known ICQ positives and well-known ICQ negatives pretty much willy-nilly, and forbidding at considerable inefficiency any sort of maker-centric usage of judgment.

but all we are saying in all three of these is really just this: we are still figuring out what ICQ really is. that's not an argument against the premise, that's an argument for efforts to get better thicker stronger senses of ICQ.

we want to ship more value faster. we don't care if that value is more features, more performance, more stability.

for all three of these, there's a C and a C', and if *this* starting C is easier to morph in to C' than *that* starting C, we'd rather start with it.

if all the possible *this* starting C's have shared attributes, we call those attributes ICQ, and when we create all our new C' code, we want that code to have those attributes.

if you shudder at a goto, or a 5000 line method or an early return or a late return or any typographical feature of a codebase, well, hell, you already bought in to the correlation premise. now we're just haggling over what is and isn't ICQ.

ICQ is meant to be entirely synonymous with "faster to change". we are still defining it, and will be for the foreseeable future. but if you care about *productivity*, you care about ICQ. if you want to go faster tomorrow, you care about the quality of the code you wrote today.

ICQ has nothing to do with the definition your customers have of value. it's not about fewer bugs or more. it's not about fewer features or more. it's not about slower code or faster. it's about going from C to C' at the maximum possible speed, regardless of the value-increment.

if you want to get inside the TDD mindset, you have to think of TDD as an approach to maximizing the production of code changes, regardless of what those code changes accomplish for the user.

and if you *advocate* TDD, i would recommend saying this loudly: TDD is not about any aspect of customer experience other than the speed with which we can offer improvements to it.

i can go faster by making C' less valuable to the user: incomplete, slower, unstable. i *can* do that, have done that, will do it again.

but i can't go faster by slowing down the rate at which i can change code. not ever.

that's the correlation premise.

here's the blog: "The Correlation Premise -- Redux". geepawhill.org/correlation-pr…