The Correlation Principle

Source

The correlation principle says that our productivity is tightly correlated with the internal quality of software.

The two go up together, and they go down together, and you can’t trade away the one to get more of the other.

“Yeah, but we can get it done faster if we settle for it working less well.”

See, here’s the thing: that’s generally true. We can deliver more quickly by settling for a lower level of value.

You can trade ESQ for time-to-market. You can make the app slower, or uglier. You can make it do fewer things. You can make it handle fewer cases in the things it does do. All of this will, generally, get you to the market faster.

Well, can we trade ISQ away to get better delivery times, the way we often do with ESQ?

Just as the answer with ESQ is “generally, yes”, the answer with ISQ is “generally, no”.

It’s because lowering ESQ makes some things easier, but lowering ISQ makes all things harder.

- 🔥

From most significant to least, the big three terms in our daily production equation are

  1. How inherently complex is the problem domain?
  2. How good is the team?
  3. How changeable is the code?

Think about how you’d alter any of these three things.

But that third thing: “How changeable is the code?” See, that’s just ISQ by any other name.

The third largest term, the easiest one for us to change, is exactly what we mean by ISQ. And that’s why we can’t trade it away for more productivity. They’re directly correlated.

Changing code is the fundamental behavior of software development teams. If we reduce the changeability of the code, we reduce the team’s effectiveness. We get less value or we get value more slowly.

- 🔥

The timescale for the impact of ISQ violations is ridiculously short, far shorter than the timescale at which the majority of your time-to-market calculations take place.

And their effect isn’t linear, either. One bad name won’t sink a ship. A hundred bad names will. And that’s one of the smaller violations. The big ones scale out of control even more quickly.

Next confusion: conflating ISQ with “clean”, its cognates, its synonyms, and its overtones. I am long on record as opposing the use of “clean” as a word to describe ISQ. Not only is it misleading about what ISQ activity looks like, it’s also misleading about the impact of low ISQ. (It’s also commonly used to suggest moral deficits on the part of people we want to beat.)

  • Relates to the Steve Yegge post and my musings on how to talk about "engineering hygiene"

Trash my ISQ and everything I do is slower.

  • 🔥
  • 💯