Anton Zaides spent a two-day hackathon building a referral tool with a recruiting team, using a generator so the non-engineers could maintain it afterward. Day one: 90% done. Day two: nothing worked. He calls it the day-two collapse, and treats it as a communication problem as much as a technical one.
Engineers have tried to explain this forever, usually badly. One of his former leaders was openly allergic to the words “refactor” and “infra work,” and after LLMs arrived the question became “can’t you just give this task to ChatGPT?”
The analogy he landed on is a house renovation, because everyone has lived in a house and no one expects one to be predictable.
- Root cause vs. bucket. A leaking roof can be handled with a bucket, but if you own the house you find the leak. Software that gets patched at the symptom layer keeps the real defect alive.
- Infrastructure before it is needed. Budget for one floor today and add the second later and you pay far more than if you had built the foundation now. The same is true of the plumbing that makes a feature cheap to add later.
- The house you never finish. Unlike a house, software is inhabited while it is being rebuilt — you update the facilities while people live inside.
His suggested answer to “why can’t you just do this one specific use case” is not a lecture about complexity. It is that the cheap thing now is the expensive thing later, and the foundation is the part nobody sees in the demo.
The fix at the hackathon was the boring one: stop the sprint, go over one area at a time — understand, plan, implement — and accept a slower pace to get a demoable flow. That process is how good software gets built, and it is the first thing dropped under time pressure.
The useful takeaway for engineers is that the argument is not “my work is hard.” It is that estimates traded for speed are deferred costs, and the house analogy gives stakeholders a reference frame where they already believe that.