Hacker News Reader

Comment by theamk | Hacker News Reader

> When a button breaks on a website, I have a model about what should have happened. Somewhere a contract got broken. [...] I might not have access to debug just an HTTP status 500, but I expect there to be somebody whose job is to understand why the endpoint is 500ing. The ownership is well-defined albeit opaque³.

> For many users, however, the actual experience is roughly just "stupid thing sucks." Software already feels capricious; more failures just change the rate of frustration.

I am betting author does not use cloud services much. It is not just "users", it's developers as well. Github is returning 5xx? AWS service does not work? Your email did not get delivered? Nothing we (developers) can do, "stupid thing sucks".

View on HN

We see this fatalistic attitude all the time in software. "Bugs are inevitable." No, they aren't! Bugs are a choice. Almost all companies choose bugs because "no bugs" is too expensive. It's sometimes the right choice but we need to acknowledge that it's a choice and not some natural property of software. Imagine if people who built bridges or airplanes thought "bridge collapses and airplane crashes are inevitable, no way to solve it."

I’ve had several occasions where I would build a feature “properly” with defensive guardrails and handling of edge cases “that will never happen (but are technically possible)” and then you run into the coworker that says “it’s overengineered. YAGNI. Just do the one-line fix”

But...were they wrong? There is a difference between "edge case" and "cannot ever happen". I've seen this trend a lot lately where Claude suggests a lot of extra code to handle things that cannot possibly happen. Unless you ask it to, it won't trace the flow of data through the app to confirm the edge case actually exists, if local conditions appear to allow it. Then the developer lets it implement this crap without asking that one question, and I have to say YAGNI in the review.

I've seen so many software bugs in my career where when you traced execution, you'd find the code crashing in a block with the comment //this can never happen

That’s not a bad thing though — what that means is that the original dev believed this could never happen and probably therefore could not decide exactly what the right way to handle the error is.

Whether they were wrong is a matter of perspective.

I think they were against over engineering because they were constantly firefighting bugs and didn’t have time to thoughtfully review.

> It is not just "users", it's developers as well.

One can be simultaneously a developer and a user. Distributed systems [0] weren't invented five years ago, after all. ;)

"Github owns this part that we rely on for correct operation and we can do fuckall about it when it fails." is a well-defined ownership model.

[0] ...implying the existence of distinct parts that can be independently developed and independently fail...

Reply on news.ycombinator.com