Best Practice Isn’t a Fact

Photo by Norbert Braun on Unsplash

I’ve just waited (another) whole day for a code review. Again. Hang the stress, hang the expense.

When it finally gets reviewed there will probably be some trivial changes that will need to be made before the PR merges. 

I honestly thought by 2026 we would be beyond this. We would be doing better than we actually are at this point.

Software development does this all the time.

We just don’t usually admit it.

Is-ought

David Hume famously identified what is now called the is-ought problem. In simple terms, you cannot move logically from describing how something is to declaring how it ought to be without introducing some additional value or principle.

So let’s go back to my code review issue.

Fact: Developers routinely wait hours for code reviews.

Value: Engineering processes should help developers produce good software without unnecessarily blocking them.

Conclusion: A code review process that routinely leaves developers blocked should be improved.

It’s the middle sentence that matters. Without it, we get silly solutions. Like measuring developers by the number of PRs they review (the number matters) rather than the quality of those reviews or other metric you would want to attach.

Software companies are absolutely stuffed with these missing middle sentences, and this is perhaps why we get such sub-optimal (that is, silly) decisions in this industry.

Two Reviewers Must Be Better Than One

I’ve previously worked somewhere that had poor code quality, which was a real problem.

People were pushing code and then it had issues.

Management identified this as a problem, and put their thinking hats on. Their solution was to require more people to approve every pull request.

That’s right. So pushing code got substantially slower. And as usual a second review became a simple rubber-stamping of the first review. That means the second reviewer seldom even read the code that the first reviewer had approved.

Sure, two seems to be better than one on the face of things. However, the point is we need better and more considered code reviews than we had before.

Fact: Code can contain mistakes.

Value: Reducing the risk of bad code reaching production requires quality code review.

Conclusion: Train and mentor developers to perform better code reviews.

Such a decision makes more sense.

Best according to what? If you have no idea why you are doing something, how can you know how to do it better?

Best Practice According to Which Unit?

Software developers love the phrase best practice, but what does it mean? Who decides what is best?

So the phrase itself develops a magical quality, and once somebody says something is a best practice, all further discussion can apparently stop.

“Why should we structure the code this way?”

Best practice.

“Why should this class have an interface?”

Best practice.

“Why do I need to reorganize these imports before you’ll approve my pull request?”

Best practice.

Excellent, and I think management thinks that *job is done* at this point.

But a practice can only be best relative to some objective.

If your objective is maximum reliability, you may make completely different engineering decisions from a team trying to get a prototype in front of ten customers by Friday.

Neither team necessarily has worse engineers.

They’re optimizing for different things.

Say the Middle Sentence

I’m not suggesting engineering teams need to begin every meeting with a seminar on eighteenth-century philosophy.

Although that might still be more useful than some stand-ups I’ve attended.

I’m suggesting something much simpler.

When somebody says:

“We should do X”

Ask:

“Why?”

And keep asking until you reach the value underneath it.

We should have two reviewers.

“Why?”

Because it reduces mistakes.

“Why do we care more about reducing mistakes than increasing delivery speed?”

Now we have the actual discussion.

Maybe the answer is obvious, maybe everybody knows. Maybe they don’t. It’s you responsibility to find out, though.

About The Author

Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.

The Secret Developer has spent years being told things are “best practice”, and has just realized that those are not the best things at all.