Today, let’s take on microtest TDD’s Correlation Premise: Internal software quality (ISQ) and productivity are directly correlated. They go up together, and they go down together.
Writing about geekery these days seems idle or frivolous at times. I’ve decided to just accept it as a way to relax here and there. But don’t mistake me.
Black lives matter. Stay safe, stay strong, stay angry, stay kind.
The correlation premise lies in direct opposition to the widespread but grossly over-simple analysis that suggests we can "go faster" by shorting the internal quality of our code. It says, on the contrary, the lower that internal quality, the lower our productivity.
Start by noting that we’re talking about internal software quality (ISQ), not external software quality (ESQ). What’s the difference? ISQ is the attributes of the program that we can only see when we have the code in front of us. ESQ is those attributes a user of the program can see.
ESQ:
The user can tell if the program is slow, ugly, case-complete, feature-rich, and so on. Most ESQ attributes can be shorted to improve time-to-market, which is our key measure of productivity. We very often can ship faster if we have fewer cases, or uglier screens.
ISQ:
Looking directly at the code, a programmer can tell it’s well-factored, it’s tested, it’s duplicate-free, it’s strongly named, and so on. But ISQ attributes can’t be shorted the way the ESQ can. When we reduce any of these attributes, we don’t go faster, we go slower.
Understanding this distinction is central to getting the premise. And misunderstanding it is one of several factors that tempt people to ignore it, however repeatedly.
We recently spoke of three major changes in the trade over the last forty years: dramatic increases in our collaboration, our complication, and our continuity.
Each of those has the effect of putting greater reliance on the ISQ of our codebases for our productivity.
In highly collaborative situations, we have two people working on one thing, and we want them to be seeing the same thing. That "sight", and the ease with which it can be obtained, is obviously very important to us.
And what do we call the bundle of attributes that make code easier or harder to "see"? We call that ISQ. That’s what factoring, naming, testing, singularity, and so on are really all about: the ease with which I can read the text and grok its meaning and intent.
The staggeringly high level of complication in modern apps makes it impossible for one mind to hold all element in focus at one time.
We are forced to switch context as we move from place to place in the code.
If contexts are hard to put down, hard to pick up, if they have no lines between them, then one of the most important factors in our ability to produce software is greatly hampered. Switching becomes expensive, we do it less readily, and as a result we work more slowly.
The increased continuity of our apps, their much longer lifespan, pressures us for higher ISQ in two ways: 1) the context switching, this time not from point to point but from time to time, and 2) the increased reliance on our ability to change code we’ve already shipped.
Expanding on the second point: Trivially, continuity means change, and the primary job of a professional geek has gone from being "build" to "change". We spend far more money nowadays doing brownfield work, not greenfield.
And what’s the first rule of changing something you shipped?
Do not make things worse than they are,
And what’s the primary factor in your ability to not make things worse than they are?
Your actual understanding of what is actually there.
There are two reasons why the correlation premise is not as well-grasped in the trade as it should be. First, the majority of geeks lack the insight about that dramatic trio of changes. Second, a pernicious mental error we call the "Lump of Coding Fallacy".
First, the three C’s.
The inexperience of the majority of geeks in the ranks is simple fact: over half of working geeks have less than five years in the trade. Many lower geek-age than the apps they are actually working on. Obvious, and not their fault. It’s just how it is.
Ironically, it’s the leadership’s experience that causes them to ignore the C’s. They have years of working solo on simple problems that were one-and-done. They don’t remember collaboration, complication, and continuity because they didn’t have it themselves.
Second, the lump of coding fallacy.
Which goes like this. "The job is changing code, literally typing in an editor. Raising ISQ means either a) typing more code or b) taking more time to type the code we type. Therefore, raising ISQ slows us down."
This analysis would be great, if only "programming" and "typing" were the same thing. They are, of course, not. The programming activity includes so very much more than just typing text. And ISQ correlates to productivity because of its support for the parts that aren’t typing.
I have a video explainer for this: The Lump of Coding Fallacy
Watch it, and if you like it, share it around your team.
ISQ: the factoring in your code, its testedness, its naming, its mapping to the domain, all of these work to improve our production because our production depends on our ability to rapidly grok the code we have in front of us, which is the first step to being able to change it.
The Correlation Premise: Internal software quality (ISQ) and productivity are directly correlated.
When ISQ goes down, so does productivity, & vice-versa. If you want to optimize time-to-market, start by optimizing the internal quality of your code.
Supporting GeePaw
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. You can also subscribe to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.