Hacker News new | ask | show | jobs
by freedomben 1345 days ago
This opinion is a popular one these days (particularly since it complements the demands of business nicely by maximizing personal/company profit), but it is a big part of the reason why the majority of software these days is so unreliable and buggy. It results in hacks on top of hacks to paper over problems in the lower levels of the abstraction tower that is modern software, and it results in tons of "WTF" bugs that are just accepted and never fixed.
2 comments

It's popular because these war stories you find in blog posts are pure survivorship bias.

If I'd let every fucking team member go on an exploratory bug hunt whenever they feel like it (hint: that would be always) we would never get anything done.

What if they don't find anything? Is this issue really worth 2 weeks of dev time? That's 15k down the drain for a senior engineer, if not more.

From a short-term business perspective, sure, it doesn't make financial sense.

As a user of software, though, I want someone to fix the bug. I want software that doesn't have bugs. So let me repeat my original statement. We need more like this that are willing to spend engineer time fixing bugs, even upstream bugs in open source projects. Instead of prioritizing shoving half-baked features out the door for next week's press release.

[Author here] Even from a short-term business perspective, it actually might make sense to fix things and contribute upstream. When you face a problem with something you built using FOSS, essentially you have three choices:

- Work around it, most likely creating technical debt inside your organization in the process

- Invest the time to fix it yourself

- Pay someone else to fix it for you (e.g. the original authors via a support contract)

None of these options is for free, and which one is the most cost-effective depends largely on the complexity of the issue at hand, the skillset and availability of the people involved and the criticality of the impacted system.

I wish, brother. I wish it was more like that...
When you need working software at the end of the sprint, there's often no time to carefully control for all edge cases.