1. 63
  1.  

  2. 23

    Lol. I’ve spent weeks hunting bugs where the fix ended up literally being a single bit change. To be clear, that’s not intended to be a flex but rather an underlining of the original author’s point that a line of code is not really a metric of anything at all.

    1. 26

      I came to say something similar. I recently found a bug in the Linux kernel in an obscure code path that no one except us and paravirtualised MIPS use (which, realistically, means no one except us). Debugging took several days. The fix was changing a 0 to a 1. Even in ASCII in the source code, this was a change of 0x30 to 0x31, so a one-bit fix in both the source and the compiled binary.

      There’s the old (and possibly apocryphal) story of an engineer coming to service something, tapping the machine with a hammer, fixing it and charging $5,000. The customer objected and demanded an itemised bill. They got this:

      • Hitting the machine with a hammer: $1
      • Knowing where to hit it: $4,999

      Fixing a bug is often trivial. Figuring out the correct fix and where to put it is the hard bit. My favourite bug fixes are the ones that involve just deleting code.

      1. 4

        There’s the old (and possibly apocryphal) story of an engineer coming to service something

        Here you are

        1. 1

          This is one of those cases where the 1 byte change should be accompanied by a multi-paragraph explanation ;-)

        2. 7

          It’s not one line of code, it’s which line of code in the millions of them.

        3. 10

          I overall agree with the post except for the following:

          Claiming there isn’t enough is a great way to look like you’re trying to help but not have to do anything.

          Unsubstantiated bug reports also encourage buck-passing behavior between departments. I wasted enough time in my career digging down root causes of bug reports passed along to me by other team members to finally discover that the issue was within components under their purview.

          Now I consider common courtesy to provide developers with a minimal scenario that reproduces the bug or, when not possible, sufficiently detailed information surrounding the failure so as not to waste the developer’s time.

          The fact that most large OSS projects request the same courtesy from their bug reporters (GCC comes to mind) comforts me in my decision.

          1. 4

            Sometimes the end-user is not-so technical, and mostly unable to grok the indications to reproduce the problem:

            Dev: can you provide me the .log files?

            User: what are logs? where are they? how to open .log files? what? no! I won’t ship you my device (was that what you were asking?).

            Issue: (after 3 weeks) “pending information from client” -> “cannot reproduce”

            1. 5

              In that case the dev should work with the user to repro the issue. Break down the communication wall!

              1. 3

                I like this way to do it. That leads to a bugfix. While it is good to avoid bothering the non-tech user with technobabble, sometimes there is simply insufficient data for meaningful answer…

                1. 3

                  Yeah, part of the dev’s job is to extract info from the user but not spout babble at them. Explaining things simply is always a good skill to have.

                  1. 3

                    Also a really damn hard one. It tends to pay dividends though.

          2. 7

            This reminded me of a snippet from Code Complete: “Why isn’t Mary coding?”

            This phenomenon is known as the WISCA or WIMP syndrome: Why Isn’t Sam Coding Anything? or Why Isn’t Mary Programming?

            If the manager of your project pretends to be a brigadier general and orders you to start coding right away, it’s easy to say, “Yes, Sir!” (What’s the harm? The old guy must know what he’s talking about.) This is a bad response, and you have several better alternatives. First, you can flatly refuse to do work in an ineffective order. If your relationships with your boss and your bank account are healthy enough for you to be able to do this, good luck.

            1. 5

              It once took me ten hours over night to delete four lines of code to fix a bug that had crept in unnoticed until the day before a big product launch. The bug in question crashed Chrome dead on our MDs laptop but no other computer we had available.

              I had resolved to rewrite a large portion of the frontend code that could be causing this mystery crash into the backend; knocking out over 5000LoC over night before finding out rewriting the feature hadn’t fixed the issue and it still crashed on the MDs laptop. Called the MD into a zoom at 5am and went through everything I had done before accidentally opening a file and saying “oh none of this does anything,” before seeing four lines of code that my gut told me where the issue, which where also entirely redundant. Deleted them, redeployed and all of a sudden the app no longer crashes Chrome on the MDs laptop.

              The product launch apparently went well, I didn’t notice as I took my self to bed and had the following few days off to “celebrate.”

              1. 5

                There’s a bug bounty somewhere in that Chrome crash.

              2. 4

                A corollary is that sometime implementing a 1 line feature can take several days to be tested. At $job, we integrate with partners that we depend on to test (we’re a glorified broker). Therefore we need to test many scenarios with them, and it can takes a few days. We have every party mocked and simulated for many tests, but nothing beats real world analysts and QA trying to find edge cases of new features.

                1. 2

                  It’s pretty well established that line-of-code isn’t a good measure for progress.

                  I don’t see why restating it is particularly noteworthy here.

                  1. 1

                    Yeah, it does seem to be a bit preaching-to-the-choir on a site like Lobsters.

                  2. 1

                    I think this is a good thing.

                    I have seen the opposite multiple times, marking many, complex changes in order to fix a bug that hasn’t really been found and therefore not understood. It’s a strategy of brute force where code around where the problem appears to appear gets changed until it somehow seems to work.

                    Sometimes the fix was done somewhat accidentally, as unintended side effect on a change that for example to ease testing. Then all of this gets commited as “fix X”, resulting in a big did where most of the change isn’t required, but might introduce new problems.

                    For this reason I got very careful when choosing a work place and try to as early as possible see the code base and how individual commits look like. This tends to also be an indication for other parts of the company working well.

                    This is of course not to say that it’s not a valid approach to quickly check things. What I criticize is not actually finding the big, therefore often not really being sure if the underlying bug was actually fixed and then simply commiting all that testing.

                    Sometimes this also appears to be done as a way to seem like having done more as the article suggests. To not just change one or two lines.

                    1. 1

                      Another story:

                      A compiler emitted the IR as comments (alongside actual assembly). E.g.

                      a = b + c
                      

                      might result in

                      ; a = b + c
                      mov r13, r12
                      add r14, r12
                      

                      Unfortunately, in one case there was no ‘\n’ after the comment, thus resulting e.g. in

                      ; a = b + c  mov r13, r12
                      add r14, r12
                      

                      The fix was a linebreak…

                      1. 1

                        I’m reading this at the wrong time because I’m bitter about a coworker changing a hardcoded file input and claiming in standup that they’ve “modified the module to take a different format”. For the record the module is somebody else’s git repo that they added to our source and claimed they’ve “integrated” and it already had the functionality to read a different file input.

                        1. 1

                          This seems like one of those questions that might be perfectly innocuous, or a big red flag. Trust your gut.

                          1. 1

                            I would say that this is a great example of what Peter Naur was trying to express in Programming as theory building.

                            All the whys mentioned are a great examples of what happen when you have not the theory and knowledge described in the chapter Programming and the programmers knowledge

                            Programmers knowledge
                            1. the dev can explain the links between program and real world
                            2. the dev can explain the links between parts within the program
                            3. the dev can respond constructively to any demand for modification
                            

                            Naur sounds kind of prophetic at the end of the introduction paragraph saying that if we don’t understand the nature of programming (which it is building a theory in his prospective) conflict and frustration will arise…