Hacker News Reader

Comment by taeric | Hacker News Reader

I don't think anyone says you should just casually ship bugs. Quite the contrary, most are ok with the idea that, if you see a bug, fix the bug. But, there can be no doubt that there is diminishing returns on chasing down every potential bug.

This reads to me like the idea that a rich person walking down the road wouldn't pick up a $20 they happen to see at their feet. Of course they will. Why not?

What they don't do, is waste time walking around looking for spare money that has been dropped. Because that would almost certainly be a waste of time.

Similarly, use your tools to write as efficient and bug free code as you can. Make it as flexible and allow for any future changes you can accommodate along the way. But "along the way" should be "along the way of delivering things in a timely manner." If you stray from that, course correct.

View on HN

> What they don't do, is waste time walking around looking for spare money that has been dropped. Because that would almost certainly be a waste of time.

Why is it usually a waste of time? Because people rarely lose multiple bills of money, and if they do, our vision system is well equipped to spot the other bills quickly.

The opposite is often true with software in my experience.

When there is a bug, it's often because the software is in a state of imbalance and confusion, and there are multiple bugs nearby.

And humans tend to be relatively bad at spotting bugs.

So, when you see a bug it is usually worth spending a moment to reflect on whether you've fixed the bug properly and whether there are other bugs in the vicinity. It is likely to be worth it just for the bug fixes.

But there's also the learning effect that comes with it as described by TFA.

Again, if you see a bug, fix it. If you are already in a section of code, read through all of it. And heck, if you are not running late on anything, feel free to start trying to re-architect parts that you think are off.

If I'm just caught by a strawman at the start of the essay, apologies on that. I legit don't know anyone that casually encourages bugs as long as you have features. Tolerances are a thing, but so is negligence.

About 30 years ago, there was this wonderful book, called Writing Solid Code[0]. Reading it, was a watershed, in my personal development.

It has many techniques described, that have since become Canon, and a number that have not aged so well.

One that is probably impractical, these days, is Step Through Your Code. He recommends stepping through every line of your code in a symbolic debugger, making sure that the code flow is what you expect, and the app state is appropriate.

Every now and then, I can do it. Often, when I’m already there, for something else. It really does work.

[0] https://writingsolidcode.com/

It's not that I know people who casually encourage bugs, but I know plenty of people who don't habitually do the kind of thing you describe in your first paragraph.

> I don't think anyone says you should just casually ship bugs.

I'm not going to link to it, but there's an old post from someone here, that pretty much sums up the zeitgeist.

They say that if the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much.

That is, quite literally, making the conscious decision to "casually ship bugs."

I mean, is that a general feel across industry, or something a rando online offered up as a witty quip? I have never worked anywhere where people were casual about shipping bugs. Some of the healthier places I've been have focused on not getting worked up when you do. Don't take pride in it, but don't sweat the small mistakes. You will make them, whether you want to or not.

I wouldn’t know, but it was certainly presented as a “general feel,” and, anecdotally, almost every interaction that I’ve personally had with “modern” tech companies (in fact, with one, it resulted in a multimillion-dollar disaster), have shown me that “feel.”

The disaster I mentioned was particularly heartbreaking, because the tech was solid, and the people behind it, were good, but they absolutely refused to give respect to Quality, and everything went to shit.

Just look at the way any discussion of Quality Development gets treated on HN. This very post nosedived, ten minutes after it posted. The only reason that it’s still around, is because it must have been “second-chanced.”

I have seen people that love to argue the straw man of why 100% code coverage is not something that will often, if ever, give 100% confidence that your product is correct. But I have never met anyone that would not agree that <50% test coverage is a red flag. Could get most people up to about 85% before they would balk at the focus.

I would take it a bit further: https://littlegreenviper.com/testing-harness-vs-unit/

Reply on news.ycombinator.com