6 ms·

“As it is assumed that there is an even distribution of bugs through all software, it is safe to consider any piece of software to be bug free once a certain nu

“As it is assumed that there is an even distribution of bugs through all software, it is safe to consider any piece of software to be bug free once a certain number of bugs have been found” Lol genius. Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident. Other times you write some crap code and it has several immediately found bugs but weirdly you emotionally feel more confident in that code because you “fixed” the bugs.

lordnacho 5y ago
> Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that. Turns out I wasn't running the new version of the function.
- gnat 5y ago
  When I was a larval programmer, I collected the different types of bugs I found as I debugged my code. This category was my favourite. I once progressively commented out more and more of a file, trying to find the bit with a bug, until the whole thing was commented out and no source was being compiled yet the original buggy behavior was still there and only THEN did I figure out I was editing a different file than I was compiling. Echoes of this original sin have shown up repeatedly throughout my life, to be point where it's one of the first things I check when my corrective measure has no effect on problematic behavior.
  - lordnacho 5y ago
    What are the other categories?
  - the_af 5y ago
    I've been hit enough times with this bug, now it's one of the first things I test. Just printing something in order to check I'm editing the right file, even before trying to fix the actual bug!
    - salawat 5y ago
      Not really a bug though. That's operator error. This week I've seen multiple people stumbling over that, and it's gotten to the point I question whether people understand filesystems anymore. Half the reason for them is to provide an abstraction that maps a spacelike addressable quality to data to be operated on. It's an extension on the more general concept of namespaces. What's the difference between data HERE and data THERE. different path. Even with stuff like git or other VCS's where you fudge the spacelike mapping with an extra layer of time-like addressing... This is the content HERE from 3 revision's ago vs. the content HERE now vs the content over THERE either now that or 3 revisions ago... I have to train people to break them of the habit/hubris of thinking they are "smarter" or more "accurate" at computation than the computer is. If you take the meaning of compute to be "creatively navigating to a solution in a problem space, humans win hand down. If you define it as reliably doing the same thing over and over again, give up. The silicon has you beat. Always check your assumptions against what the machine is actually doing. Checklist if necessary. That puts you on a footing where you can actually outdo the computer in both realms. Or don't and be reminded once again of why being human is the most pitiable form of cognitive logic, where it takes hard work just to ensure a consistent response to similar classes of stimulus over time, and where remembering and recalling things is totally non-trivial. In the quest for staying alive in a dynamic world doing it's best to kill us, our brain does great. In a world in which it'd be nice not to be reminded by my equipment of my own idiocy on a regular basis, not do much.
      - kodah 5y ago
        A programmers view of code isn't exactly one to one with a filesystem though, so I don't think it's that programmers have trouble understanding filesystems. Instead, I think it's that many languages push us into particular paradigms of code organization. That filesystem now quickly reflects the programmers mental model of the application within the confines of the language. Often in those paradigms I find that there's layers to a single feature; for instance, it may be implemented via a hook that calls a controller that calls a service. Those layers exist to group code and to allow for future development, but they can also get confusing about what you're touching in large codebases.
  - Akronymus 5y ago
    This is why, when compiling, I have "everything" pulled up, sorted by change timestamp and check if the file I care about actually has changed.
  - 8n4vidtmkvmk 5y ago
    i had an nginx "bug" where it was serving an old version of a file. i deleted the file and hard refreshed and it still served it up happily. turns out i had static gzip compression enabled and never deleted the corresponding gz file
  - segfaultbuserr 5y ago
    Fun fact: Unix Makefile was invented as a result of this incident. > Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. - Stuart Feldman
    - Too 5y ago
      Oh the irony. Makefiles has been the number one source of this issue itself. Usually due to badly specified transitive dependencies. Like only rebuild .o files on changes to .c files but forget completely about changes to .h files etc. Removed c files leaving stale .o files still being linked in is another favorite. But yeah, I guess the predecessor it replaced must have been even worse. Today we can have higher expectations.
      - NieDzejkob 5y ago
        My favorite solution is Tup, which uses FUSE to observe exactly which files each command is reading. That way it's impossible to write a Tupfile for which incremental builds don't work properly.
        iforgotpassword 5y ago
        I was actually thinking of this approach once but immediately convinced myself it's crazy. Good to see it seems to work at least. :-)
      - rustybolt 5y ago
        I also remember changing the makefile, mindlessly running 'make' without looking at the output, then running the program and wondering why the program isn't behaving differently.
  - ithkuil 5y ago
    This class of issues is so common in my personal experience that very often I intentionally introduce some sort of panic/assertions in the place that I want to fix, just to be 100% sure I'm a) editing the right source b) the tooling (compiler, ci, ...) is actually doing what I expect. Most of the time it's unnecessary, but when it catches such issues it saves countless hours of frustration.
- scottlamb 5y ago
  I do that all the time. And I just [1] did the reverse: I tried to track why a bugfix wasn't working, only to realize my user was running a version that predated the fix. D'oh. [1] https://github.com/scottlamb/moonfire-nvr/issues/209#issuecomment-1086264326 https://github.com/scottlamb/moonfire-nvr/issues/209#issueco...
  - yjftsjthsd-h 5y ago
    Hah, yes; the number of times I've accidentally run ansible with --check (dry run) and then wondered why the server wasn't restarting...
- jlokier 5y ago
  The best refactor is the one you accidentally commit using the smooth, virtuoso commit command only for masters of the art, "git reset --hard". Fingers have a mind of their own sometimes. (Next was something to snapshot the VM, followed by "apt-get install ext4magic". It worked!)
  - bqmjjx0kac 5y ago
    Is `git reset --hard` not undoable with `git reflog` and another `git reset --hard`?
    - jlokier 5y ago
      No, it wipes all local changes to tracked files in your worktree that haven't been committed yet.
      - nerdponx 5y ago
        I really wish it would warn you with a y/n prompt before doing this. Same with `git checkout` when overwriting unsaved files. You should need a `--force` option to bypass the prompt. Or it could simply refuse to make the change without `--force`.
- kergonath 5y ago
  This happens to me all the time. “Dammit, I thought I fixed that damn stupid bug an hour ago” before realising I effectively hit “run” instead of “build and run”.
  - a1369209993 5y ago
    > before realising I effectively hit "run" instead of "build and run". This used to happen to me all the time too. The solution I ended up going with was to standardize all my build scripts on `./build run` as the way to (build and) run the program, with the actual binary getting shoved in ./bin/ or something to discourage running it directly (which also reduces clutter). Basically, get rid of the "run without building" command entirely.
- anamax 5y ago
  I start by inserting asserts that fail. I keep at it until the expected failures occur. As I fix things, I move those failures.
  - ed25519FUUU 5y ago
    I do this also. Is there a word for it? I also start a mocking by putting an assert in the function I’m mocking to make sure my mock covers it.
    - czx4f4bd 5y ago
      I think the Red-Green-Refactor loop is pretty close. I learned TDD via obeythetestinggoat.com and it really instilled in me the urge to see a test fail before I trust it when it passes. Sometimes I forget to check that my test fails the first time, so I’ll go back and deliberately break the function under test just to see it fail.
      - anamax 5y ago
        A test that never fails is a slow comment.
- CodeWriter23 5y ago
  >> Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident > I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that. Either way, it’s just confirmation bias.
- sgtnoodle 5y ago
  For my current work project I've gone full C++. It's all constexpr and templates, though, so as long as it compiles it should be bug free!
hdjjhhvvhga 5y ago
Well, although this RFC is probably a 4/1 joke, there is some truth in the first part: assumed we are talking about state-of-the-art open source project where many people can actually inspect the code and are interested to do so, with the amount of bugs per LoC already found you decrease the chances of finding more bugs in the future provided that you don't add new ones. This can be seen in projects considered "mature" where no new features are being implemented. Of course the second part is ridiculous: unless we are talking about a system formally proven to be bug free, which has enormous limitations, there always will be bugs.
DaiPlusPlus 5y ago
> Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident. Other times you write some crap code and it has several immediately found bugs but weirdly you emotionally feel more confident in that code because you “fixed” the bugs. Ever since I started adopting TDD, FP-style and using "Railway oriented programming", and always running static-analyzers as part of the build process far more often-than-not my code not only works correctly on first-run, but stopped getting bug reports. It felt weird at first but now it's weird to see my code not work on the first run.
Arnavion 5y ago
There have been a few times when I wrote complicated Rust code involving mutable borrows moving around lots of scopes, expecting the compiler will yell at me and I'll have to rewrite it a lot, but it compiled fine the first try. It makes me suspicious every time that I've done something wrong. Of course there was the one time when it was an actual compiler bug, heh. https://github.com/rust-lang/rust/issues/51117 https://github.com/rust-lang/rust/issues/51117
valw 5y ago
April fool's joke : we'll pretend that bugs in software are distributed as a homogeneous Poisson process, AND that Poisson distributions are bounded, while we're at it. Poisson d'avril!
akavi 5y ago
No, the exact opposite for me: Code that works on first run is almost always actually bug free; if I find one bug in a piece of code, then I almost always fine more eventually.
jacquesm 5y ago
Bugs are like mice: when you see one there will be 10's, when you see 10's there will be 100's. But if you see none, there really might be none. Though that's pretty rare, usually it just means you have friendly and well formatted input.

lordnacho 5y ago

> Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that. Turns out I wasn't running the new version of the function.

gnat 5y ago
When I was a larval programmer, I collected the different types of bugs I found as I debugged my code. This category was my favourite. I once progressively commented out more and more of a file, trying to find the bit with a bug, until the whole thing was commented out and no source was being compiled yet the original buggy behavior was still there and only THEN did I figure out I was editing a different file than I was compiling. Echoes of this original sin have shown up repeatedly throughout my life, to be point where it's one of the first things I check when my corrective measure has no effect on problematic behavior.
- lordnacho 5y ago
  What are the other categories?
- the_af 5y ago
  I've been hit enough times with this bug, now it's one of the first things I test. Just printing something in order to check I'm editing the right file, even before trying to fix the actual bug!
  - salawat 5y ago
    Not really a bug though. That's operator error. This week I've seen multiple people stumbling over that, and it's gotten to the point I question whether people understand filesystems anymore. Half the reason for them is to provide an abstraction that maps a spacelike addressable quality to data to be operated on. It's an extension on the more general concept of namespaces. What's the difference between data HERE and data THERE. different path. Even with stuff like git or other VCS's where you fudge the spacelike mapping with an extra layer of time-like addressing... This is the content HERE from 3 revision's ago vs. the content HERE now vs the content over THERE either now that or 3 revisions ago... I have to train people to break them of the habit/hubris of thinking they are "smarter" or more "accurate" at computation than the computer is. If you take the meaning of compute to be "creatively navigating to a solution in a problem space, humans win hand down. If you define it as reliably doing the same thing over and over again, give up. The silicon has you beat. Always check your assumptions against what the machine is actually doing. Checklist if necessary. That puts you on a footing where you can actually outdo the computer in both realms. Or don't and be reminded once again of why being human is the most pitiable form of cognitive logic, where it takes hard work just to ensure a consistent response to similar classes of stimulus over time, and where remembering and recalling things is totally non-trivial. In the quest for staying alive in a dynamic world doing it's best to kill us, our brain does great. In a world in which it'd be nice not to be reminded by my equipment of my own idiocy on a regular basis, not do much.
    - kodah 5y ago
      A programmers view of code isn't exactly one to one with a filesystem though, so I don't think it's that programmers have trouble understanding filesystems. Instead, I think it's that many languages push us into particular paradigms of code organization. That filesystem now quickly reflects the programmers mental model of the application within the confines of the language. Often in those paradigms I find that there's layers to a single feature; for instance, it may be implemented via a hook that calls a controller that calls a service. Those layers exist to group code and to allow for future development, but they can also get confusing about what you're touching in large codebases.
- Akronymus 5y ago
  This is why, when compiling, I have "everything" pulled up, sorted by change timestamp and check if the file I care about actually has changed.
- 8n4vidtmkvmk 5y ago
  i had an nginx "bug" where it was serving an old version of a file. i deleted the file and hard refreshed and it still served it up happily. turns out i had static gzip compression enabled and never deleted the corresponding gz file
- segfaultbuserr 5y ago
  Fun fact: Unix Makefile was invented as a result of this incident. > Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. - Stuart Feldman
  - Too 5y ago
    Oh the irony. Makefiles has been the number one source of this issue itself. Usually due to badly specified transitive dependencies. Like only rebuild .o files on changes to .c files but forget completely about changes to .h files etc. Removed c files leaving stale .o files still being linked in is another favorite. But yeah, I guess the predecessor it replaced must have been even worse. Today we can have higher expectations.
    - NieDzejkob 5y ago
      My favorite solution is Tup, which uses FUSE to observe exactly which files each command is reading. That way it's impossible to write a Tupfile for which incremental builds don't work properly.
      - iforgotpassword 5y ago
        I was actually thinking of this approach once but immediately convinced myself it's crazy. Good to see it seems to work at least. :-)
    - rustybolt 5y ago
      I also remember changing the makefile, mindlessly running 'make' without looking at the output, then running the program and wondering why the program isn't behaving differently.
- ithkuil 5y ago
  This class of issues is so common in my personal experience that very often I intentionally introduce some sort of panic/assertions in the place that I want to fix, just to be 100% sure I'm a) editing the right source b) the tooling (compiler, ci, ...) is actually doing what I expect. Most of the time it's unnecessary, but when it catches such issues it saves countless hours of frustration.
scottlamb 5y ago
I do that all the time. And I just [1] did the reverse: I tried to track why a bugfix wasn't working, only to realize my user was running a version that predated the fix. D'oh. [1] https://github.com/scottlamb/moonfire-nvr/issues/209#issuecomment-1086264326 https://github.com/scottlamb/moonfire-nvr/issues/209#issueco...
- yjftsjthsd-h 5y ago
  Hah, yes; the number of times I've accidentally run ansible with --check (dry run) and then wondered why the server wasn't restarting...
jlokier 5y ago
The best refactor is the one you accidentally commit using the smooth, virtuoso commit command only for masters of the art, "git reset --hard". Fingers have a mind of their own sometimes. (Next was something to snapshot the VM, followed by "apt-get install ext4magic". It worked!)
- bqmjjx0kac 5y ago
  Is `git reset --hard` not undoable with `git reflog` and another `git reset --hard`?
  - jlokier 5y ago
    No, it wipes all local changes to tracked files in your worktree that haven't been committed yet.
    - nerdponx 5y ago
      I really wish it would warn you with a y/n prompt before doing this. Same with `git checkout` when overwriting unsaved files. You should need a `--force` option to bypass the prompt. Or it could simply refuse to make the change without `--force`.
kergonath 5y ago
This happens to me all the time. “Dammit, I thought I fixed that damn stupid bug an hour ago” before realising I effectively hit “run” instead of “build and run”.
- a1369209993 5y ago
  > before realising I effectively hit "run" instead of "build and run". This used to happen to me all the time too. The solution I ended up going with was to standardize all my build scripts on `./build run` as the way to (build and) run the program, with the actual binary getting shoved in ./bin/ or something to discourage running it directly (which also reduces clutter). Basically, get rid of the "run without building" command entirely.
anamax 5y ago
I start by inserting asserts that fail. I keep at it until the expected failures occur. As I fix things, I move those failures.
- ed25519FUUU 5y ago
  I do this also. Is there a word for it? I also start a mocking by putting an assert in the function I’m mocking to make sure my mock covers it.
  - czx4f4bd 5y ago
    I think the Red-Green-Refactor loop is pretty close. I learned TDD via obeythetestinggoat.com and it really instilled in me the urge to see a test fail before I trust it when it passes. Sometimes I forget to check that my test fails the first time, so I’ll go back and deliberately break the function under test just to see it fail.
    - anamax 5y ago
      A test that never fails is a slow comment.
CodeWriter23 5y ago
>> Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident > I did this yesterday. I was writing a variation on a function to draw some stuff in the terminal. When I ran it, it worked fine, no crash or anything like that. Either way, it’s just confirmation bias.
sgtnoodle 5y ago
For my current work project I've gone full C++. It's all constexpr and templates, though, so as long as it compiles it should be bug free!

hdjjhhvvhga 5y ago

Well, although this RFC is probably a 4/1 joke, there is some truth in the first part: assumed we are talking about state-of-the-art open source project where many people can actually inspect the code and are interested to do so, with the amount of bugs per LoC already found you decrease the chances of finding more bugs in the future provided that you don't add new ones. This can be seen in projects considered "mature" where no new features are being implemented. Of course the second part is ridiculous: unless we are talking about a system formally proven to be bug free, which has enormous limitations, there always will be bugs.

DaiPlusPlus 5y ago

> Anyone else ever do that thing where you write some good code and it works the first time you test it, but somehow that makes you feel less confident. Other times you write some crap code and it has several immediately found bugs but weirdly you emotionally feel more confident in that code because you “fixed” the bugs. Ever since I started adopting TDD, FP-style and using "Railway oriented programming", and always running static-analyzers as part of the build process far more often-than-not my code not only works correctly on first-run, but stopped getting bug reports. It felt weird at first but now it's weird to see my code not work on the first run.

Arnavion 5y ago

There have been a few times when I wrote complicated Rust code involving mutable borrows moving around lots of scopes, expecting the compiler will yell at me and I'll have to rewrite it a lot, but it compiled fine the first try. It makes me suspicious every time that I've done something wrong. Of course there was the one time when it was an actual compiler bug, heh. https://github.com/rust-lang/rust/issues/51117 https://github.com/rust-lang/rust/issues/51117

valw 5y ago

April fool's joke : we'll pretend that bugs in software are distributed as a homogeneous Poisson process, AND that Poisson distributions are bounded, while we're at it. Poisson d'avril!

akavi 5y ago

No, the exact opposite for me: Code that works on first run is almost always actually bug free; if I find one bug in a piece of code, then I almost always fine more eventually.

jacquesm 5y ago

Bugs are like mice: when you see one there will be 10's, when you see 10's there will be 100's. But if you see none, there really might be none. Though that's pretty rare, usually it just means you have friendly and well formatted input.