Weeks of Coding Save Hours of Planning
A tongue-in-cheek reminder that skipping planning to start coding faster usually costs far more time than the planning would have saved.
"Weeks of coding save hours of planning" is a satirical saying that makes fun of how a developer's first reflex is to skip planning and jump straight into writing code. It's a tongue-in-cheek reminder that while it might feel like you're making progress by writing code, you may not actually be building the right thing at all. The joke flips the obvious sentence around: hours of planning save you weeks of coding, not the other way around.
The temptation is real in most projects, because planning feels slow and writing code feels like progress. Endless discussions are exhausting and can feel like a waste of time, while writing code is fun and produces something tangible.
But the unsolved questions don't disappear. They show up much later instead, as wrong assumptions, missing edge cases, features nobody actually wanted, and entire systems built around a misunderstanding. By the time the gap is visible, the cost of fixing it is measured in weeks of rewriting, not hours of conversation.
A short conversation with a stakeholder can collapse a "two-month feature" into a one-week feature, or reveal that the feature wasn't needed at all. An Event Storming session can show the part of the domain everyone had a different mental model of. Getting the Ubiquitous Language right catches where two teams use the same word for two different things.
This connects to the broader Domain-First Approach: invest time in understanding the problem before committing to an implementation. The cost of changing a sticky note is near zero. The cost of changing a deployed system that already has users is high. Most of what looks like Accidental Complexity in mature systems traces back to decisions made before anyone fully understood the problem.
This isn't an argument for endless meetings or analysis paralysis. It's a reminder that planning is work, and the right amount of it is almost always more than your gut is telling you.
References
- Introduction to DDD Lite: When microservices in Go are not enough — States '5 days of coding can save 15 minutes of planning' to argue that you should make sure you're solving the right problem before writing any code. Frames understanding the domain and talking to stakeholders as a strategic prerequisite to implementation.
- Software Dark Ages — Phrases it as 'With 5 days of coding, you can save 1 day of planning' when warning against rushing to code to finish earlier. Notes that the unasked questions don't disappear, and Strategic DDD tools like Event Storming exist to surface them before any code gets written.
- Becoming a Product Engineer: First Steps — Robert opens the episode with 'Five days of coding can save one day of planning' and returns to it throughout. Uses concrete examples of how a short stakeholder conversation collapsed a two-month feature into a one-week task, or revealed the feature wasn't needed at all.
- How to Create PRs That Get Merged The Same Day — Cites the saying while explaining that the root cause of big, unmergeable PRs is a lack of deep enough planning. Discusses why developers are allergic to planning meetings and prefer typing code over discussing design, even when the upfront design would shrink the PR significantly.
- AMA #1: Clean Architecture, Learning, Event-Driven, Go — Robert references the saying when discussing how skipping design produces surprising PRs that take ages to review. Argues that the time you'd spend planning is shorter than the time you'll lose to back-and-forth review and rework once a surprising PR lands.
