That’s a quick job.

Some mistakes are recognized not by a decision but by a sentence that keeps repeating. This story is about one such sentence. It is deliberately kept general — no client, no project, no date. What remains is the warning sign and the lesson behind it.

Situation

In one engagement, there was a constant push to build before anyone understood what was supposed to be built. Every question about requirements, every consideration of structure was brushed aside with the same sentence: “That’s a quick job.” Analysis was seen as delay, architecture as a detour. The wish was unambiguous: start immediately, deliver visibly, leave out the thinking.

Initial assumptions

At first we took the sentence for ordinary impatience — a preference that could be discussed. The assumption was that the value of thinking ahead would become apparent on its own once building was underway: we would simply do the analysis quietly in the background, carry the architecture along invisibly and serve the desire for speed on the surface. Impatience, we thought, could be calmed with results.

Problem

The sentence was not about speed. It expressed a conviction: that analysis and architecture have no value — that the visible typing is the actual work and everything before it is overhead. Under that conviction, every hour spent understanding the problem looked like a loss and every architecture question like a brake. The engagement was set up in such a way that the most valuable part of the work was the least welcome. Rework, misunderstandings, a moving target — none of these was read as the predictable price of the skipped analysis, but as our failure to be fast enough.

Root cause

The cause was not impatience, nor any single decision. It was a divergence in how each side understood where the value of software comes from. “That’s a quick job” assumes the hard part is writing the code. In truth, the hard part is deciding what gets built and how it has to fit together. When these two views collide, no amount of speed can suffice — because what was skipped is exactly what prevents the problems that are later blamed on slowness. We had treated a difference in worldview like a difference in taste.

Decision

The decision was not a better process for such projects, but to stop taking them on. We learned to hear the sentence for what it is: a reliable, early signal that the part of engineering that makes software durable is not wanted. Batunet now deliberately declines projects that begin this way — not out of pride, but because you cannot do good work where the foundation of good work is unwelcome. The promise “a quick job” is made at the beginning, at the widest point of uncertainty, before anything is understood. Making it would mean promising to guess.

Trade-offs

Declining a project has a price. We turn down undertakings that might have gone well and forgo revenue that was within reach. We accept that the signal is not perfect — some who say the sentence would come around over time. We decline anyway, because the asymmetry is clear: the price of a rare wrong refusal is one lost project; the price of a wrong acceptance is months of work on a foundation nobody agreed to, with disappointment on both sides at the end. We decide differently when the sentence is a single offhand remark rather than a recurring attitude — impatience is human; a worldview shows itself in the pattern.

What we learned

Part of the most important information about a project lies in how it begins. One sentence can carry an entire model of what software is. The lesson is not “always analyze” as a rule — rules replace thinking. It is that the willingness to understand before building is not a phase you can skip; it is the precondition for everything after it. Whoever wants to skip it is not asking for speed, but for a different kind of work than the kind that lasts. Estimating without analysis is not fast — it is guessing early and paying late.

How it changed Batunet

Internally, the sentence has become shared vocabulary. When we hear it — from a prospect, in a first conversation — we name it and take it seriously as a signal instead of smoothing it over. It has changed what we say yes to. We would rather do fewer projects right than more projects on foundations we know are supposed to carry the load and cannot. Saying no early is now part of how we protect the work.

Further reading

• Guide: Software that still runs in ten years — why the decisions made before the first line of code determine the lifespan.
• Decision: Modular monolith as the starting point — structure is chosen deliberately, not skipped.
• Playbook: Designing a public API — design before you build.
• Opinion: Why premature abstraction creates complexity — understanding before building does not mean building structure you don’t need yet.
• Glossary: Cone of Uncertainty — why “a quick job” at the beginning says nothing about effort.

The most expensive sentence in a project is rarely the one spoken loudly. It is the one considered harmless and therefore not heard.