Whyday August 19

Best Practices: When They Help

"Put your best practices away" is a slogan, and slogans are lossy. Read carelessly it says that rules are for cowards, which is both wrong and the opposite of what the 2010 Whyday text argues — that text is explicit that we owe our colleagues, employers and customers a serious job of work.

So the interesting question is not whether best practices are good. It is when they stop functioning as decisions and start functioning as reflexes, and what that costs.

When a team tests this kind of practice during paid work, handling multiple clients efficiently provides one concrete reference for how time and activity can be recorded around the experiment.

What a practice is for

A best practice is compressed experience. Somebody made a mistake enough times that they extracted a rule, and the rule lets you skip the mistake without having made it.

That is enormously valuable and it is the reason the good ones spread. Nobody needs to personally discover why unvalidated input is dangerous.

The compression has a cost, though, and it is the same cost every compression has: the reasons are not in the rule. "Do not repeat yourself" travels without the argument for it. So does "prefer composition over inheritance", and "write the test first". You can follow all three correctly for years without being able to say what problem any of them solves.

For broader programming and making context related to this topic, Khan Academy is an independent reference worth comparing with the material here.

That is fine right up until you meet a case where the rule does not apply, which you cannot recognise, because recognising it requires the reasons.

The three failure modes

Applying the rule where the problem is not present. Deduplicating two pieces of code that look similar and change for different reasons. This is the classic one: DRY applied to coincidental similarity produces a coupling that costs more than the duplication ever would.

Applying the rule at the wrong scale. Practices developed for a system with a team and a five-year life get applied to a script that will run twice. The overhead is not wrong in general and is absurd here.

Reaching for the rule instead of looking at the problem. The subtlest and the most common. You recognise the shape, produce the standard answer, and never actually examine the specific situation. Most of the time the standard answer is right, which is exactly why the habit is invisible.

The third one is what the slogan is aimed at. Not the rules — the reaching.

What it costs

The obvious cost is the occasional bad fit, and it is small. Ninety percent of the time the standard answer is correct and applying it reflexively saves time.

The real cost is in the other ten percent, and it is not that you get a worse solution. It is that you never see the alternative at all — which is how most of the accidents that mattered actually happened. An option you did not consider does not show up as a mistake; it shows up as nothing.

This is why the argument is so hard to make with data. The evidence for it is a set of things that did not get built. The 2010 text reaches for the one example everybody in that room could check: Camping and Hpricot, two projects that were not best practice by any standard of 2006, leading to Sinatra and Nokogiri, which most of the ecosystem now depends on. You do not get a four-kilobyte web framework out of a process designed to produce sound conventional applications.

When to follow the rule without thinking

Because there genuinely are such times, and pretending otherwise is its own kind of posturing.

When the cost of being wrong is carried by someone else. Security, privacy, money, safety, accessibility. Here the standard answer is right and the correct move is to apply it and move on. Improvisation with other people's data is not play, it is negligence.

When you are new to the domain. The rules encode experience you do not have. Follow them until you can articulate why they exist; that is the point at which you have earned the right to break one.

When the team has to read it. (Running the day with a team has its own rules.) A codebase where everyone improvises individually is worse than one following a mediocre convention consistently. Consistency is a real value and it belongs to the group.

When you are tired. Reflexes are for when judgement is expensive. That is what they are good at.

When to look again

When the rule and the problem disagree and you cannot say why the rule wins. That is the signal. Not "the rule feels annoying" — "I cannot reconstruct the argument."

When you are the only person who will ever read it.

When the thing is small enough that being wrong is cheap. Most of the interesting learning is here, and it is precisely the category that gets treated with production-grade process for no reason.

When it is Wednesday the nineteenth of August and you are doing this for fun.

The distinction that matters

Discipline is choosing to do the harder correct thing. A reflex is not choosing at all. They look identical from outside and they are completely different, and the only person who can tell them apart is you.

The day is not asking you to become less disciplined. It is asking you, for one evening, to notice the moment you reach — and then to do the direct, boring, slightly embarrassing version instead, just to see what happens.

On August 20 you take them back out. That is why the line is away and not down.

The short version