A blog said perfection has one right answer. Then HN built a concrete treehouse.
A developer argued that a "perfect" piece of software is just whatever's left once you tighten every constraint enough — and that over-engineering only happens when you've solved the wrong problem. WebAssembly co-founder Ben Titzer had a rebuttal in one line: build a treehouse out of concrete and steel, and see how perfect that looks.
A Senior Staff engineer at Google who works on the Perfetto tracing tool called the underlying premise "a very simplistic take" — constraints trade off against each other and rarely collapse to one answer.
Another reply described the worst codebase of their career: a team building an elaborate microservices architecture for a web app with fewer monthly users than the commenter's own hobby website.
The claim: tighten the constraints enough and only one answer survives
The post's core move is redefining a familiar complaint. Over-engineering, the author argues, isn't excess craftsmanship — "over-engineering is solving the wrong problem. That's the whole definition." Get the requirements honestly right, the argument goes, and tighten every real constraint — deadline, budget, the team's actual skills, the actual performance need — and you converge on one shape that fits all of them. That shape, however elaborate it looks from outside, is the perfect solution for that case, not an over-engineered one. The author reframes internal tools, libraries and APIs as products with real users, arguing that most "over-engineering" complaints are a symptom of nobody having done that requirements work honestly. Picking serverless over other hosting models is offered as one example of a constraint-driven choice: right for one team, wrong for "someone else" who doesn't know Python.
That single move — over-engineering redefined as a requirements failure rather than an excess of care — is what the rest of the thread spent the day taking apart.
'A very simplistic take': an engineer who works on Google's tracing tools pushes back
"I agree with the actual principle I think this article is trying to put across... but I strongly disagree with the framing... Constraints are not rigid and unchangable but flexible things which can bend to solve the problem at hand... And because they trade off against each other, tightening them leaves you with several solutions, each fitting a different trade-off... So no, I don't think you enumerate the constraints and find the only solution which fits; this is a very simplistic take on the complexities of building software." — Senior Staff Software Engineer at Google, working on the Perfetto tracing tool
Constraints, in other words, don't usually narrow to a single point — they define a Pareto frontier of several defensible answers, and picking among them is still a judgment call, not a formula.
The treehouse test, from WebAssembly's co-founder
"Over-complicated is adding too many features, too much mechanism, too many moving parts. Over-engineering is far exceeding the requirements in an unhelpful way. For example: build me a treehouse... If you made it out of concrete and steel, it might be a heck of a lot stronger and last a heck of a lot longer... Too strong is over-engineered. If you made a treehouse with 13 bedrooms and an elevator, glass windows, solar power, and running water, that's overcomplicated." — WebAssembly co-founder, former V8 compiler techlead
The distinction matters because the original post collapses both failure modes into one: "solving the wrong problem." A concrete treehouse solves the right problem — shelter, durability — just far past what anyone asked for. No amount of requirements-gathering makes overkill into a category error.
The clusterfuck one commenter still thinks about
"The worst clusterfuck I've ever worked on was a web application that was actually solving a real problem fairly well, but the team was spending time building an absurd Rube-Goldberg contraption of microservices when the entire platform had less MAU than my hobby website. It wasn't the wrong problem, but it certainly was over-engineered!" — an engineer describing the worst codebase of their career
A JPEG-to-PNG converter got the same treatment from a different angle: one reply ran through a hypothetical solution built on custom CUDA decoders and a plugin framework, versus a single ImageMagick command piped through find — an engineer who mocked the definition with a one-line ImageMagick command pointing out that both solve the stated task, so "wrong problem" can't be what separates them. What separates them, several replies agreed, is effort spent past the point anyone would notice or care — a category the original post's own framework has no name for.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
The Document Foundation blamed Microsoft for lock-in. HN blamed the author instead.
Italo Vignoli of The Document Foundation argues Microsoft's real lock-in tool isn't Windows or Office, it's the OOXML file format: thousands of pages of ISO-standard spec that only Microsoft's own software actually implements correctly. One commenter had a sharper read on why the argument keeps losing: Vignoli, they said, has spent years writing this same essay instead of helping LibreOffice fix the compatibility gaps that send users back to Microsoft.