Two days of thinking or six months of regret. Pick.
If you think you don't have time for a conception phase, you really don't have time for the dumpster fire that happens without one. When backend planning earns its keep, when to skip it, and the deadlock that taught me the difference at 3am.
A haunting is a bug whose root cause is a decision nobody made.
Early in my career I joined a startup. Fintech. Real money moved through the code.
The VP of R&D announced "we move fast and break things." Then he left for a month-long strategy retreat in Bali. I inherited the codebase.
No plan. No docs. No comments. Race conditions all the way down.
The bug that owned me was a deadlock in the withdrawal module. I spent two weeks on it, powered by an unsafe volume of energy drinks. Somewhere around 3am the thread dumps started reading like "abandon all hope."
A deadlock is a bug in an agreement between lines. Two code paths take the same resources in different orders, then wait on each other forever.
The fix is trivial once you know the agreement: who takes what, in which order, always. The catch was that no such agreement existed anywhere. Not in a doc, because there were no docs. Not in a comment, because there were no comments. Nobody had ever decided the ordering. It had accumulated, one hotfix at a time.
Those two weeks were archaeology: reconstructing intent from behavior, trace by trace, for code whose intent never existed.
That wasn't bad code. That was a haunting.
Bad code has an author. You can read it, curse it, argue with it, fix it. A haunting has no author. You can't fix a decision nobody made. There's nothing there to fix. You can only pay for it at 3am.
And all of it happened because nobody spent two days thinking before they spent six months building.
Planning used to bore me. I thought the conception phase was the part of backend work you endure before the real job starts. Then I shipped enough unplanned backends to learn the truth, and it fits on a sticky note: if you think you don't have time for a conception phase, you really don't have time for the dumpster fire that happens without one.
Conception is the how phase: engineering working out how to build a thing everyone already agreed to build. Whether to build it, and for whom, is discovery. Different phase, different failure modes, different post.
What two days would have bought
One page. Not forty.
The components. Which component owns each piece of state. The order in which shared resources get taken. What happens when a withdrawal and a balance update collide.
That's the whole page, and the class of bug I lost two weeks to lives entirely inside it.
Writing that page costs an afternoon of arguments. Skipping it cost two weeks for one bug, in a codebase that was race conditions all the way down. The math is lopsided and it only gets worse, because hauntings breed. Every new feature built on an unwritten agreement adds more code that silently depends on it.
But those two weeks do not prove every project needs a plan. They prove that some mistakes cost much more to reverse than they cost to prevent.
Plan it or skip it
The conception phase does not always earn its keep.
| Plan it | Skip it (mostly) |
|---|---|
| Complex, event-driven systems | Small, self-contained service |
| Distributed teams, many APIs | Known stack, known patterns |
| Brand-new, unproven tech | A veteran team that has done it before |
| Hard latency targets, high volume | Tight agile loop, fast feedback |
| Picky stakeholders and regulators | The Kanban board is the plan |
Left column, plan. Right column, stop reading and go build.
The left column is everything where mistakes are expensive to reverse: decisions baked into event schemas, into API contracts other teams already consume, into latency budgets you promised a regulator.
The right column is everything where the feedback loop is faster than any document. A three-day microservice tells you it's wrong by Thursday. A design doc for it is slower than the code it describes.
Forcing a heavyweight design doc onto that three-day microservice is its own kind of malpractice. The skill isn't "always plan." The skill is knowing which column you're standing in.
The five ghosts
When you do plan, you're chasing five ghosts. Chase them on paper now, or meet them in production later. They don't go away. They just change venue.
Scalability. Does your cache survive a thundering herd, or only a quiet Tuesday? Average load never killed anyone. The worst minute does. A cache that's warm most of the day still hands your database the entire load at the exact moment the hot keys expire together.
Data integrity. Two stores answering the same question will eventually disagree. The plan names the source of truth before corruption spreads. Skip that and the stores decide for you, silently. Bad data gets read, trusted, and written back somewhere else. You can roll back a bad deploy in minutes. Corrupted data that already spread has no rollback button.
Security, disaster recovery, backups, monitoring. These unglamorous siblings never win sprint planning on their own. They have no demo. No stakeholder asks for them until the day everyone asks at once. The conception phase is the only room where they reliably get a line item, which is half the reason the room exists.
Deployment. A half-baked Kubernetes config is a planning gap biting you three months late. Deployment decisions are architecture decisions that get reviewed like chores: what happens when a node dies mid-request, whether two versions of the service can run side by side, what a rollback actually rolls back.
Honest tradeoffs. Elegant versus shipped this quarter. The shiny new database versus the 2am pages it bills you later. Every technology choice is a loan, and the plan is where you read the interest rate. A tradeoff you never wrote down was still made. It was made by nobody, and it binds everybody.
You already know what I call those.
The other malpractice
None of this is a license to gold-plate everything. Premature optimization is a sin, and a design doc nobody reads is theater with extra steps.
Worse: a doc that produced no arguments found nothing.
You're shipping the disagreements. The doc is just the minutes. If the conception phase ends with everyone nodding, you didn't plan, you transcribed.
The point is to have the fight about lock ordering in a meeting room, where it costs an hour, instead of in the withdrawal module, where it costs two weeks and your 3am.
Two days or six months
Somewhere there's a backend you're about to start building. It'll get a conception phase either way. The only question is whether it happens now, on one page, or later, in the withdrawal module.
Decide the agreements that are expensive to reverse before code makes them expensive. When the feedback loop is faster than any document, go build.
I learned the difference in the withdrawal module, at 3am, trace by trace. Two days of thinking now, or six months of regret later. Pick.