Technical judgment vs. shipping speed: when each one wins

There’s a false dichotomy that goes around engineering teams: either you ship fast, or you ship with judgment. As if they were mutually exclusive. They are not. But they aren’t the same thing either, and confusing them has a real cost.

The false-choice trap

When a product manager asks “can we have this by Friday?”, there are three honest answers:

1. Yes, and it will hold up for six months.
2. Yes, but it will only hold up for six days without touching it.
3. No, unless we get Monday to design it properly.

The frequent mistake is to answer “yes” without flagging the difference between option 1 and option 2. A month later, when we have to add a small feature on top, we discover that “technical debt” was not debt: it was a compound-interest loan.

When speed wins

There are decisions where speed is legitimate, even correct:

• Validating a product hypothesis. If you don’t know whether users will use the feature, designing the definitive architecture makes no sense. Cheap and fast wins.
• Critical incidents. The site is down. The payment gateway is broken. This is not the time for refactor; it’s the time for hotfix.
• Non-negotiable external deadlines. A campaign with a launch date, a client with an investor pitch, a fiscal close. Reality calls the shots.
• Throwaway code. A landing page for a weekend event. A migration script that runs once. Elegance is a luxury that doesn’t pay off here.

In these cases, writing “the perfect code” is ego, not craft.

When judgment wins

Judgment wins on the opposite side:

• Architectural decisions. Database schema, public API contracts, module boundaries. Here every shortcut gets paid over years.
• Code that will be read a hundred times. If five developers will touch a module over the next two years, clarity pays off far more than writing speed.
• Security and sensitive data. There is no “we’ll improve it later” here. Later arrives when an attacker finds the gap or when legal calls about a leak.
• Onboarding the next developer. Code is written once and read a hundred times. If you need to explain it every time someone new joins, you’re already paying interest.

The question is not “do we prioritize speed or judgment?”. It is “how many times will we have to touch this code over the next two years?”. If the answer is many, judgment wins even when the deadline is tight.

The Monday-morning test

A practical heuristic I use with clients:

Imagine it is Monday morning, another developer (not you) opens this file for the first time. How long does it take to understand what it does and how to change it?

If the answer is “ten minutes”, the code is good. If the answer is “a whole morning reading and praying”, the code is debt disguised as a feature.

This test deliberately ignores “easy to understand because the author is brilliant”. Code is not measured by the intelligence required to write it, but by the intelligence required to read it. Donald Knuth said it better: “Programs must be written for people to read, and only incidentally for machines to execute.”

The false saving of “we’ll clean it up later”

There’s a phrase I hear in many sprints: “let’s do the quick version and refactor afterwards”.

In four years of production, I have seen that “afterwards” arrive exactly zero times. Not because people lie, but because the moment to refactor never comes: there’s always a new urgent feature, a new critical bug, a new tight deadline. And the debt grows.

My rule: if the code will live more than a month in production, refactor it before merging, not after. Even if it seems slower, you save yourself rewriting it once it has three dependencies on top.

How judgment looks in my work

When I join a project, I ask three questions before touching anything:

1. How long will this live? A landing for a one-off event does not deserve the architecture of a SaaS platform.
2. Who will maintain it? If nobody on the client’s team will be able to touch it, then I keep it as simple as possible even if the result is less elegant.
3. What breaks if this fails at 3 AM? If the answer is “nothing important”, I can afford to experiment. If the answer is “the business stops”, judgment wins, no exceptions.

The difference between haste and speed

There’s a distinction I learned writing philosophy and apply every day to code: haste is not the same as speed.

Speed is delivering what’s needed in the time available, without wasting steps. Haste is skipping steps to arrive faster and discovering later that you arrived at the wrong place.

A fast team ships quickly without generating debt. A rushed team ships quickly and the debt is paid next quarter.

Conclusion

There is no universal answer. But there is a universal test: the day you ship, honestly ask yourself how much the next change will cost. If the answer is “the same or less”, you chose well. If the answer is “more, because I’m now building scaffolding to hold this up”, then you didn’t ship fast: you shipped haste.

Technical judgment is not the opposite of shipping fast. It is the only way to ship fast twice in a row.