five underplayed premises of TDD, here, geepawhill.org/musing-five-un… includes the correlation premise.
the correlation premise says "internal quality and productivity are directly correlated". confusions and misunderstandings around this premise abound furiously, so it's worth taking some time and working it out in detail.
when we say internal quality (IQ) and productivity are directly correlated, we mean that they go up together and they, sadly, go down together. their trend lines are inextricably linked.
the first thing we have to do to parse this is make sense of internal (IQ) vs external (EQ) qualities, because a lot of the confusion starts right there.
external quality (EQ) includes any attribute of a program that a user can experience.
is it correct? EQ. is it useful? EQ. is it fast, pretty, graceful, stable, complete? all of this is EQ.
on the other hand, internal quality (IQ) includes any attribute of a program that only a coder can experience.
IQ is visible only in the source, and implicitly only by someone who can grasp and manipulate that source.
is it minimal? IQ. is it tested? IQ. is it well-named, well-factored or jointed, easy to read? these are all IQ.
the correlation premise says that you can't trade away IQ to get higher productivity. and there's the first source of confusion: because you *can* trade EQ for higher productivity.
this is obviously the case: under nearly all circumstances, it takes more time to make a program faster, or prettier, or to include unusual corner cases, or to be exact instead of approximate.
if you don't care about rare corner cases, that's less thinking i have to do and less code i have to write. that's less *time*, and i can spend that time usefully on other, ideally more important value. so EQ trades pretty easily for productivity.
IQ doesn't work that way. the reason is because software development productivity is at its base exactly about *humans* *changing* *code* *correctly*.
if we sat down and wrote what economists call the production function for software development, we'd get some massive complex polynomial. plug in the variables, give that crank a turn, and get out of it how much production you get in a day or week or year.
the three largest terms of that polynomial are these: the skill of the code-changer, the fundamental complexity of the domain, and the "changeability" of the code that has to be changed.
the code-changers's skill can be improved, but it requires experiences, and the massive demand for software means that every year there are fewer and fewer experienced code-changers available proportionally to serve that demand.
the fundamental domain complexity can also change, usually in the form of a dramatic paradigm shift. sadly, this is both wildly unpredictable and almost entirely outside of our ready control.
what about the changeability of the starting code? now, my friends, we are cooking with gas. because there's another name for "changeability of the starting code". it's called "internal quality".
all of the IQ things are all of the design principles from the last five decades of geekery are all of the TDD/refactoring things, and every single one of them is about making life easier for *humans* *changing* *code* *correctly*.
internal quality can't be traded for productivity because it's the most malleable of the top three terms in the software development production function.
there are two more confusions that hamper the newcomer's thinking about all this, and our trade is swamped with newcomers, so we need to call them out.
the first is the conflation of internal quality with the word "clean", its variants and cognates, and the fifth column of overtones and metaphors that come with it.
i strongly oppose this usage, so much so that when someone speaks it i am often almost completely blocked from carrying the discourse further until it's resolved.
when i make function-preserving alterations to code, when i refactor, in other words, i am directly and simply maintaining and increasing the internal quality term of my development production function.
when i do it pre-emptively and habitually, i'm doing it from the mature recognition that there are patterns of high internal quality, and that following those patterns makes me more productive,
when i do it immediately prior to touching some code to implement a new story, i am doing it because implementing that story will be easier -- faster -- in a high-IQ codebase, and refactoring is easier -- faster -- than interpolating new function in low-IQ code.
i am not "cleaning", because that word is deep-laden with overtones and metaphors that don't reflect what, how, or why i am refactoring. most notably, it comes with ideas of optionality and morality, neither of which are present in my idea of refactoring.
i won't belabor the moral thing now, except to point out to non-native speakers of english that whole generations of us were raised on the adage "cleanliness is next to godliness", and for those outside of the judeo-christian tradition, sloth is one of the seven deadly sins.
as for optionality, it's really a form of delayability ("delay forever"), and that's the third big confusion around the correlation premise. here we go.
the argument is made, from the "clean" stance but also from entirely separate impulses, that we do have to refactor for high internal quality, but we don't have to do it *now*.
assuming a perfect golden codebase, almost any new value i add will make it less golden. (this is a complicated thing, and i don't want to explain it now, so i'm asking you to trust me on this.)
the "eventually" argument admits that sooner or later we must "re-golden" the base, but that we can delay doing so, because the cost of re-goldening, refactoring, need not be borne until we have to add more value to the code we just added.
this is an argument about how soon low-IQ kicks in during the production function. if it isn't immediate, we can stall, right?
and there's the confusion. you see, it *is* immediate. because the lowering of IQ affects the production function so quickly, stalling just isn't a viable strategy.
you doubt me. that's okay, join the club. (no, *back* of the line, please. we'll announce your number when it's your turn.)
let's take an easy example.
let's take an easy example.
how soon does a weak name for a variable, method, or class start affecting your production function? refactorers are obsessed with names and naming.
well here's the thing, in programming, the only reason to introduce a variable, method, or class, and to name it, is so you can begin using it. whatever that cost is, you start paying it the very second time you enter it.
and remember the thinking knee, and the clever workaround called "chunking"? names and their attendant metaphors *dramatically* affect our ability to chunk.
if you're old-school enough to have ever had to change computer-generated code, like yacc output for instance, you'll know something else: it doesn't take very many weak names to render code virtually un-think-aboutable.
remember that internal quality is all about supporting humans changing code correctly? anything un-think-aboutable doesn't just slow down the changing of code. it stops it dead.
so there ya go. the correlation premise says "internal quality and productivity are directly correlated." you can't trade one to get more of the other. they go up together, and, sadly, they go down together.
here's your blog post: "Underplayed: The Correlation Premise In Depth" geepawhill.org/underplayed-th…
