Detail: Not The Long Game

I was gratified by the response to my first "detail" article. But I did note that many persons praised my article for its commitment to the long game.

Framing the commitment, for a geek, to detail, as a long game, seems right, sounds right, cuz after all, we only ever care about quality in the long game.

And this is why y’all can’t convince anyone to do this or think this or feel this.

When does a bad variable name take effect? A year from now? Two years? When we’re all old and gray, and some silly whipper-snapper is stuck maintaining our shite?

No.

A bad name takes effect the very moment you make it.

Bad names, weak chunking, hard-to-read code or tests, all of these things work instantly.

They are a micro-payment, a tax, on your ability to program.

"Micropayment?", you say, "What’s a micropayment? Micropayments are nothing."

Yes.

Except you’re all using google for search, & for email, & for docs, and how’d they get all that money to do all that?

Micropayments, yo.

Your heart is in the right place, in seeing the detail for what it is. But your math is in the wrong place.

Attention to detail isn’t a long game, it’s a ridiculously short one.

External quality — everything a user can tell about your software — is one thing. Internal quality — everything a developer can tell about your software — is another.

You can trade external quality for time to market. Make it uglier. Make it slower. Make it handle the three most common cases and to hell with the rest. All of these are external quality, and when you lower them, you get to market sooner.

But internal quality, by contrast, can’t be traded for time-to-market. The level of internal quality — unlike that of external quality — correlates directly with improved production.

It’s called the correlation premise: internal software quality and productivity go up together, and they go down together. There is no inverse relationship there, it’s direct. You can’t trande internal quality for faster time to market.

Think about it. Write out the long complex multi-term equation that will capture what your team is able to ship today. It’s a mess, but there it is. Now sort the the three largest terms.

The first term is the skill of your geeks. The second term is the complexity of your domain. The third term is . . . the code they started with this morning.

What’s easiest to fix?

The skill level of your geeks?

The complexity of your problem domain?

Or the internal quality of your code, the "what they started with this morning"?

I think you know the answer.

We gotta get past the idea that software development somehow isn’t change, that it, somehow is laying bricks, that typing somehow is the bottleneck.

We gotta stop talking about long-term rewards, and the wonder of external quality.

Don’t look at me. Look at AdWords.


Does the GeePaw Blogcast add value?

If so, consider a monthly donation to help keep the content flowing. You can also subscribe for free 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.

close
Want new posts straight to your inbox once-a-week?