Hacker News Reader

Comment by jongjong | Hacker News Reader

After 15 years of software development experience, I've been thinking about this a lot lately. It's like you don't stop learning to be more careful. Even after 15 years, my mind is expanding. Sometimes I find code that I wrote 2 years ago which, at the time, was produced with far more care and extreme pedantic attention to detail than the average developer would have given it, yet it was still not correct for ALL POSSIBLE edge cases. It's insanely difficult to produce correct code. I'm starting to have thoughts like "Has anyone in the world (aside from Knuth haha) written a single program which is over 10K lines of code and which is 100% bug free right now? Does such program exist?" I don't even believe that Bitcoin is bug free; it just has too many lines.

View on HN

I think about this pretty often from the opposite perspective. As a frequent user of software, I can't get over how much it all sucks. Nearly every nontrivial piece of software I've ever used has had annoying and frustrating bugs and it feels to me like that's only getting worse. I agree that there's no correct software and I think the software engineering discipline needs to be blamed more for it. I don't think we deserve these salaries just to churn out broken code. I love programming but you can bet that the second there's an AI that can write perfect code, I'm advocating for it to replace us all because I'm tired of broken software.

Well, there is a massive force that acts directly against not doing broken code - people(read managers and stakeholders) don't want to wait, they want the value for their money now, and from their perspective a certain degree of brokenness is fine

As long as it works "well enough" a broken product that ships now is better than a perfect product that never ships.

Yes, but also this very easily turns into shipping absolute crap, that in itself can cause a good concept to flop. There is a balance to be had, and at least some decent minimum requirements on what is good enough to ship. You neither want to overdosing, nor ship the first draft that sort of kinda works, and that second thing happens way too often.

Fully resonates with me. The complexity and bloat of many modern software has gotten out of control to the point that even users end up being victims; in spite of all the additional effort, workarounds and automated testing undertaken to try to shield them from it.

Developers are fallible humans and almost every single developer tends to underestimate the complexity and difficulty of what they're dealing with. Even those developers who are naturally good at coding are nowhere near where they need to be to produce merely correct code. Not outstanding, readable code, just correct code.

Modern software has become an inseparable amalgamation of people and code because the code on its own is just not good enough. DAOs which can operate on their own with minimal to no human intervention are still a pipe dream.

Hey, did you hear about the company that wrote perfect software?

No, they went out of business to some other company that wrote imperfect software with a lot more features a lot faster!

Especially in the '90s I remember hearing the "Why does everyone use X, it sucks and it crashes", and yet whatever X was tended to have a broad range of features clients needed.

I recently watched a video about craftspeople who spent a lifetime mastering their particular craft and one was a Japanese calligraphy brush maker who had been working on a particular brush for 25 years. He called it “no compromise craftsmanship”.

It made me wonder what a “no compromise craftsmanship” computer or software would look like. For one, it would never truly get done, there’s always more to do, but then again I guess that’s the same with the 25 year calligraphy brush.

> It made me wonder what a “no compromise craftsmanship” computer or software would look like.

Dwarf Fortress fulfills each point of your criteria, and some more that I could add. It's an epic achievement.

I don't play it. I've never invested the brain cycles it would take to learn the interface, and I know that if I did I'd fall into a deep, deep hole that'd compromise every other priority in my life.

Oh, yes! DF is an excellent example.

I don’t play it either, I tried it once or twice and it was just too much for me. I might try their new graphical steam version that they released last year sometime, it looks a little more accessible.

What software are you using and what were last 10 frustrating bugs you encountered?

I find it fascinating because my use of software seems bug free in last 5-10 years. It is hard for me to run nowadays into a frustrating bug.

When I was in high school there were just loads of bugs and everything seemed broken it was 2005ish and before. Windows was crashing now and again, had to reinstall frequently, software was crashing taking my work with it so I still have compulsive ctrl-s tick.

I couldn't tell you the last 10 bugs I saw (they are too frequent and varied to memorize), but here are the most common bugs I run into:

- Firefox randomly freezes up on Android (Google Pixel 6a), and then sometimes this crashes my phone and causes it to spontaneously restart. This usually happens at least once a day, often more, despite being very widely reported for a very long time.

- Assorted Adobe software develops strange behavior after it has been open for a while (selected items stop showing as selected, some tool or editing technique spontaneously stops working, exported images are borked, pressing ctrl+S reports that it has saved the file but it actually has not, etc). I have probably seen 50+ unique failure states over the last couple of years. I am affected at least a couple times a week, and I have learned to restart my software several times a day as a preventative measure.

- On desktop (Windows), some website will fail to load something or it may display bizarre behavior (erratic scrolling long after the page has loaded, back button stops working, links stop working, video playback stops working, etc.). Usually reloading the webpage fixes it, but sometimes the tab itself has broken or the browser has to be restarted. Other times, it's a consistent bug in the website and there is nothing to do but wait a couple days for them to fix it. I usually see website/browser issues like these about once a week or two.

It's better than the 90s, but it's still pretty bad and could be way better (as proven by all the software/systems/sites out there that don't have so many bugs).

> I find it fascinating because my use of software seems bug free in last 5-10 years.

It doesn't have to have an explicit bug in order to be shit.

There's too many instances where something is doable, but only painfully so. copy/paste over the last 10-15 years is a perfect example of something that isn't bugged but is complete shit in most software nowadays.

search is another one, how often have you been on a website where ctrl+f doesn't work right because subsequent data only loads after you scroll below the fold? no bugs, but still shit software.

> What software are you using and what were last 10 frustrating bugs you encountered?

I actually tried writing a section of my blog called "Everything is Broken" to cover some of the ways software breaks in (as well as some issues in general): https://blog.kronis.dev/everything%20is%20broken

Unfortunately, there are so many bugs out there, that I only write about the things that are annoying enough to push my hand. Some of the last things that happened to me:

  * Ubuntu LTS updates broke my GPU drivers, preventing the server from starting up (among other things)
  * Debian updates made some unnecessary piece of software start listening on port 25, thus breaking my mailserver in Docker
  * OpenProject packaged PostgreSQL inside of a single container, except that didn't bother setting up automatic data migration for new major version
  * Vector maps are somehow way more laggy than raster tile based maps, horrible user experience on mobile for me (video included)
  * a trailing comma in Visual Studio Code configuration file made fonts end up being non-monospaced
  * Kdenlive (probably due to ffmpeg) failed to correctly apply text titles on top of a video at the correct times
  * containers break due to different file system permission models on Window and Linux, bind mounted files have incorrect line endings
  * Nginx crashes the entire web server if something like 1 out of 20 reverse proxied domains doesn't have a successful DNS lookup on startup
  * Grav (blogging software) can have changes be made to the install without admin authorization, my blog got vandalized
  * Oracle database randomly dropped connections, some relation to a generated column

I've also had issues with GRUB, disk management in Linux, Nextcloud, Libre Office, OpenCV, Docker Swarm and pretty much every class of software (desktop, web, CLI tools, GUI stuff, OS components) out there - sometimes in pretty exciting ways of them breaking!

I also have a folder on my computer where I collect screenshots of software breaking out in the wild, currently it has 143 images, though perhaps that's a bit too much for blog posts. Currently the last 10 there are:

  * Mozilla Observatory failing to analyze my site due to their own CSP being broken (script-src)
  * PHP install failing because the ondrej/ubuntu PPA failing to work like it should
  * my bank login page having an untranslated text string for one of the options: #xml-dtd.LOGIN-TEXTS.LOGINEPARAKSTS
  * my mobile service provider telling me that I've used 212166% of my mobile data
  * me being unable to modify a Visual Studio Build Tools install locally because they want to update their installer but I'm offline
  * Windows 11 Explorer breaking the file path bar and showing me two overlapping text strings for some reason
  * Oracle not giving me my OCA cert because my name contains non-ASCII symbols
  * the War Thunder game telling me that I have 2147483647 crew available for my tank
  * OpenProject functionality to move multiple issues failing... despite them having a dialog exactly for that
  * installing a Ruby Gem following official SQLite instructions results in UDS:Trojan-Downloader.Win64.Alien.eg/ef being detected

Aside from that, perhaps my favorite bug is this: https://i.imgur.com/97wu8j5.jpeg

I see here bunch of:

- not really a bug, just system was not build to support scenario - not really a bug, user does not understand system thinks it should work differently - not really a bug, combination of 2 or more software things that have no way of knowing about each other - not really a bug, because it does not affect me in any meaningful way

There are some I can agree are bugs of course. Though I see I am getting older and much more humble and lenient.

For humble it is that if I expect some software to work some way and it does not, I step back and really go back to understanding documentation and what it all means. I don't call out things "fail to work like it should" (which of course might be my issue and parent poster might be right calling it out).

Then for lenient, I just don't care about labels, text misalignment etc. The same with expecting non-ASCII symbols being supported, yeah we have UTF for quite some time, but it is also not something trivial to switch to and company most likely has loads of other work to be done.

In the end world is not about me and there are tons of users who have other issues and my edge cases are not affecting enough people. World is much bigger so to say. If it does not affect me in any meaningful way I just move on.

That's a very fair point, that's why I had to mention the whole "(as well as some issues in general)" thing as well.

For example, if software works in a configuration that was setup correctly (according to their own instructions) in version #1 and after update the version #2 makes the setup no longer work, is that a bug? I'd probably say it is, unless the patch notes clearly instruct that something needs to be done, though even that can be debatable. What about the case where you don't even consent to install some package that will take up a port on your OS and break something else, but it silently gets pulled in through some update? There's probably nuance to it all.

At the end of the day, as a user, I might subjectively not even care about the internal workings behind some abstraction and the many reasons behind it, but rather about how it should work in a reasonable configuration - if a web server refuses to start if it cannot resolve a domain that it's supposed to reverse proxy when starting up, even though the other 19 out of 20 could be proxied, is that a bug? Probably not, but it sure seems pretty darn broken, since those 19 could be served and the faulty domain simply checked later.

Of course, the software itself doesn't care about the user either, so at the end of the day it is the user who needs to learn patience and to trudge through the docs, posts online and other sources to hopefully resolve the issues, even if it's a bunch of weird workarounds or concessions, no matter how frustrating they might be. But hey, there's nothing wrong with documenting said frustrations or issues.

I am glad that you've embraced a more neutral mindset, though!

> I am glad that you've embraced a more neutral mindset, though!

Putting on the proverbial blinders and declaring software "better now" is not really something I'd consider neutral, to be honest. Sounds like expectations dropping over time, more than anything. Note how there are plenty of real examples of outright bugs that are left unaddressed here and no acknowledgement that yes, the world of software is full of them.

I don't particularly care whether someone has a rosy outlook in general, but it's pretty odd to declare that software is somehow so good when it's at the very least as bad as it was in the early noughts.

It's understandable that people don't like overly pessimistic people dooming and glooming too much but I find the inverse equally if not more annoying. If you factor in how much slower most software experiences are vs. what our hardware should achieve plus all of the bugs that are at least as plentiful if not more our general software output is much, much worse than it ever was. We're not even producing it much faster because of galactic scale overcomplication in software stacks as well.

Some things I could come up with off the top of my head. I wrote down every bug I found in programs for a week or so at one point and the list was way, way longer than I thought it would be. It highlighted that despite my fairly pessimistic view on software there's a lot that went unnoticed because I just don't even expect it to work very well anymore.

I would encourage you to write down bugs when you see/experience them but in all honesty I don't know that it will give you much; it will probably only completely destroy your positive outlook on things that you seem to have retained.

- On YouTube sometimes the interactive elements of a video (quality settings, etc.) will also scroll my page down about 15% when I interact with them. If I click on the settings wheel to change the speed of the video that's 3 clicks and I'll end up ~50% scrolled down from the video I'm watching.

- YouTube randomly resets my settings for inline playback when I disable it. With inline playback "Add to watch later" is not available as a thumbnail hover option.

- When I was running Windows it would randomly set my bluetooth headset volume to close to zero out of nowhere without any changes made on my end, but only on a reconnect, so I would always have to check every time I connected whether it had done it.

- Sometimes when my bluetooth headset connects on Linux I'll just plain have no sound at all despite it saying it's connected. The workaround is to just reconnect.

- During a routine package upgrade for some reason something installed `xdg-desktop-portal-gnome` and this made every application that uses GTK (I think) start about 10 seconds slower. Uninstalling this package solved it.

- Thunderbird will leave an empty e-mail subject line sometimes when I delete an e-mail I've received, but the body it shows when I click it is another e-mail I deleted.

- World of Warcraft will randomly lose connection despite there being zero connection issues and rejoining will immediately work. This happened maybe 3-4 times per week in the 3 week period I played recently.

- Discord sometimes just removes my key binding for toggling push-to-talk.

- Elixir (via `mix`) refuses to compile dependencies sometimes and solutions range from having to remove folders, update deps and all manner of things. There's usually no real rhyme or reason to it and we all just nuke a folder or two and move on.

- Same as above but with `node_modules`.

- We had a package from `npm` that would sporadically not type check with our usage and we could never figure out what it was caused by. Every 20th or so build `tsc` would report a type error where none had existed before. This was with pinned versions.

- When I used VSCode I would regularly end up in a situation where VSCode suddenly started saving files super slowly and took forever to auto-format code. This happened with at least 3 different languages so it was not language or extension-specific. I've also seen it happen live to at least 3 other people.

- Plex will die when playing video files of a certain quality on my TV despite playing them fine for ~15-20 minutes.

Bug free code isn't pragmatic at all.

For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge cases.

One thing that I've found myself doing in recent years is to simply let the program blow up and have the end user experience a 500 error. I know this isn't ideal for so many orgs but I've come to the conclusion that the worst thing you can have happen is a feature that breaks but returns a "200".

> One thing that I've found myself doing in recent years is to simply let the program blow up and have the end user experience a 500 error. I know this isn't ideal for so many orgs but I've come to the conclusion that the worst thing you can have happen is a feature that breaks but returns a "200".

Acceptable for webapps. I can't really think of anywhere else that it becomes acceptable to simply say "We had an oopsie. Try again later".

Mostly what you want to do is give the user an actionable error message - i.e. "This is what you can do to fix this error".

"cd /somedir" gives errors of the form "permission denied" (i.e. change your perms level, or ask the owner of the dir to change its permissions), "not found" (i.e. that dir does not exist, so create it if you need it), "i/o error" (i.e. your disk may be bad, run fsck), "Not a directory" (i.e. specify a directory, not a file), etc ...

With most programs written in HLL these days, all I get is something along the lines of "Operation could not be completed", or, worse an exception handler that has absolutely no clue what is needed to fix the error (a real one I got last week: "expected integer, got string". I have no idea where in the 3k lines of input that field actually is, or what it is called).

The only good error messages I see are written in programs that don't have exception handlers, so the error is printed out where and when it happens, and the programmer who wrote the code that generated the error is also forced to handle it, and so has all the context to generate a reasonable error message.

OP here. This is one of the exact things that, in my mind, makes programming hard. It probably wasn't covered in the post, but striking the right balance between "bug free" and "pragmatism" towards accepting lack of functionality and error tolerance, is crucial.

Within certain domains like healh-care (my area these days), space travel, military, edge case management play a significant role in the valuation of where to place your effort (although it doesn't exclude the ability to fail fast and hard during development cycles). In other domains exposing users for these hard failures is considered perfectly fine. It depends...

It's just one other aspect - when thinking beyond just the code - that makes the decisions and consideration I have to make every day "hard".

This is so true. I see a lot of bad APIs and returning something like a 200 response + a message body saying something like "Psych! Actually it'd broken" is a surprisingly common anti-pattern.

Reminds me of Petet Gabriel's Worse Is Better[0], one of the insights of which is that it's often better to fail for edge cases than try to handle every single one.

[0] https://dreamsongs.com/WorseIsBetter.html

This particular thing is a matter of opinion, there are pro's and con's to each approach.

The question is what constitutes an error and should web semantics and application semantics align?

should I return a 404 on a missing record, and if I do, how can I differentiate between that and a routing error?

My point is that you're confidently stating something where both sides are neither right nor wrong, they simply value different things.

We had to do this in order to show the user a relevant error message because our system is behind apache and it doesn't forward the content body from wsgi for (IIRC) whole classes of error codes.

Another almost worst thing is having production environments with significantly different stacks to what you are using locally, with branches in the code to account for this.

This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally.

And it deploys from one of our old crappy Jenkins pipelines that decided 30 minutes ago to start having a failing volume.

Should have just used GitHub Actions + Postgres.

>Another almost worst thing is having production environments with significantly different stacks to what you are using locally,

Everyone has a test environment, some people also have a seperate production environment :D

Database/datasize issues typically are the worst here. Dev/UAT environments are typically considered a cost center and you'll commonly see them with some small amount of ram and compute resources. Which is fine when you're testing 'small data'. But if you have enterprise style clients that have hundreds of gigs/terabytes of data, your dev environment behavior is generally going to be very different.

Ran into a case where an enterprise client ran massive db performance problems. We found an unindexed table scan that was killing performance. When doing a post mortem on it, it turns out that 95% of our customers only had around 5 entries in the table. No reason to add an index to that. But this customer had found a neat and interesting workflow that had added thousands of entries to that table.

>This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally.

Did you consider running a second test instance of the DB in the cloud?

> Did you consider running a second test instance of the DB in the cloud?

This is using the test instance :) The issue replicates both on prod (cloud) and test (cloud).

But not locally. So a nice 30 minute deployment pipeline run to test if your fix worked, since we are firewalled from direct DB connections from local dev machines, even for test instances.

I've got a 10 min lag. Now i don't feel so bad.

SOP though..

> For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge cases.

There's a spcetrum between 'all the edge cases' and 'most of the edge cases'. A web app for a blog is not exactly like an automat onboard the JamesWebb telescop...

As long as you're fixing and preventing the 500 in the future, this is how you build stable software.

it's not possible to predict everything, so instrument, let your software be loud, and listen to it.

Bug-free is more about how narrow the spec is.

Can your GUI app works on a Windows 95 with Polish as the system langauge while using a Chinese input method, and the user holding Alt all the time? Probably not. But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case?

> But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case?

I don't even think it is necessary to ask that question. The only question that should be asked for something like this is "How do we handle all unsupported use-cases?"

Because then it becomes simpler, when an edge-case causes the software to freeze, to detect for that edge-case and hand it off to the "not supported" handler.

In the best case scenario, we simply detect whether the use-case is supported and then either proceed or hand control to the not-supported-handler.

In the worst case scenario, when the bug report comes in, we don't even bother trying to reproduce it, we just add a general check for it and move on to the not-supported-handler.

In this particular case, the detection can do any one of the following:

1. Check for english, and if not, display "unsupported language". 2. Check that input language and system language match, or display unsupported". 3. Check that the OS is supported, display "unsupported OS" if not. 4. Check that the input is valid (i.e. no special codes, whether by holding down halt or otherwise), or display "unsupported input".

Whether the spec is narrow or wide, the developer needs to do the work to ensure that the user is running within spec.

Not checking results in more "bugs" that are, as you said, use-cases which shouldn't be supported anyway.

>"How do we handle all unsupported use-cases?"

Until you find out that your operating system handles 95% of unsupported cases in one way, then uses a hidden API to deal with the weirdness of other languages and the unsupported case isn't detected in that last 5% of languages. Of course that never came up in testing because who uses a hebrew/japanese combination and now the error message being returned by your application has nothing to do with the actual problem.

Your worst case scenario is just the common edge case bug handling that support/QA/dev's handle every day.

I don’t know about bug free, but Code Complete claims that the space shuttle project shipped a million lines of code with no bugs in production.

Somewhere Edward Kmett has a great post about how he realised he was just writing buggy code that would have to be thrown again away and away, and that was the point where he switched to writing Haskell libraries that were perfect and could live forever.

> which is 100% bug free

define "bug free". In Python, I've been reimplementing monads recently. It's such a shame that Python still doesn't have Null/None propagation. After each obtained result and before using it in the next chain, I have to run a series of sanity checks (is it Null or not, etc.) which should be resolved automatically by the language. Alas, most people don't care.

Something like this would be nice:

    result =? foo(bar :? str)

meaning that foo should receive a str bar, but maybe bar is not str. Then foo should return something, but maybe it returns None (the =? part).

This is an interesting idea- I'm not sure I understand it fully though. Do you have much luck with static type analysis? I find in Python, nothings ever certain, but mypy with good type hints solves a lot of these kind of None based shenanigans.

I have heard about mypy but haven't seriously used it. Type hinting has helped a lot (basically you'll end up writing Python like it's Rust), but something like the Maybe monad (my example above) would reduce a lot of boilerplate.

Something like that would fail the code review at any large organization. Why? Because ternary operator is hard for maintenance purposes so the reviewer would simply ask to use if..else syntax instead. I gather you never worked in such organization.

Not the OP and not a fan of ternary operations, but if programming were left to large organizations we would still be writing .asp pages.

Which is to say that inovation happens only when you try to do stuff just a little different each time, so I’d say that code reviews as currently implemented at those big organizations is against long-term programming-related innovation.

That is not the ternary operator.

But following the setting of the gp comment, that operator would fail code review as well. Because the book of sacred rituals says so.

The goal isn't to produce perfect code, the goal is to evolve to perfect code.

This gets missed by so many developers, once you change your mindset on this, you'll find you write better software.

One of the questions to ask when writing code is "how long will it take to discover if this goes wrong?". Make it quick to find, let someone else in the future deal with the imperfections.

I'm not saying don't try for perfect code, I'm saying not having written perfect code isn't a problem and it isn't a failing. code evolves to be stable, it is not born that way.

Reply on news.ycombinator.com