Monday, July 13, 2020

You've only added two lines - why did that take two days!

It might seem a reasonable question, but it makes some terrible assumptions:
  • lines of code = effort
  • lines of code = value
  • all lines of code are equal
None of those are true.

Why did a fix that seems so simple when looking at the changes made take two days to complete?
  • Because the issue was reported with a vague description of how to recreate it. It took me several hours to get to a reliable reproduction of the item. Some developers would have immediately gone back to the person reporting the problem and required more information before investigating. I try and do as much as I can with the information provided. I know some developers don't like having to fix bugs, and so do whatever they can to get out of it. Claiming there isn't enough is a great way to look like you're trying to help but not have to do anything. I know that reporting errors can be hard, and I'm grateful for anyone who does. I want to show appreciation for error reports by trying to do as much as possible with the information provided before asking for more details.
  • Because the reported issue was related to functionality, I'm not familiar with. The feature it was to do with was something I rarely use and is not something I've ever used in great detail. This meant it took me longer than it might to understand how to use it and the nuances of how it interacts with the software with the bug.
  • Because I took the time to investigate the real cause of the issue, not just looking at the symptoms. If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error. No error, no problem. Right? Sorry, for me, making the problem invisible isn't the same as fixing it. "Swallowing" an error can easily lead to other unexpected side-effects. I don't want to have to deal with them at a point in the future.
  • Because I investigated if there were other ways of getting to the same problem, not just the reported reproduction steps. One set of reproduction steps can easily make the error appear to be in one place when it may actually be more deep-seated. Finding the exact cause of a problem, and looking at all the ways to get there can provide valuable insights. Insights such as how the code is actually used, where there might be other places with possible (other?) problems that might need addressing, or it may show inconsistencies in the code that mean an error is caused (or handled) in one code path but not another.
  • Because I took the time to verify if there were other parts of the code that might be affected in similar ways. If a mistake led to the bug, the same error could have also been made elsewhere in the code-base. Now's a great time to check. 
  • Because when I found the cause of the issue, I looked to find the simplest way of fixing it that would have minimal risk of introducing side-effects. I don't want the quickest possible fix. I want a fix that isn't likely to cause confusion or other problems in the future.
  • Because I tested the change thoroughly and verified that it addressed the problem for all the different code paths that were affected. I don't want to rely on someone else to have to test that what I've done is correct. I don't want a bug to be found in the future and for me to have to come back to this code when I've mentally moved on. Context switching is expensive and frustrating. Having a dedicated tester have to look at the "same" change again is something I want to avoid whenever possible.

I don't like having to fix bugs. Partly because they can feel like the result of a previous failure on my part. The other reason I don't like fixing bugs is that I'd prefer to be working on new things.

What's worse than having to fix a bug?
Having to fix the same bug repeatedly.
I take the time to make sure any bug is totally fixed any time it is encountered so that it doesn't need to be faced, investigated, fixed, and tested more than once.


25 comments:

  1. Lovely post... I will take the liberty of copy pasting this into my email should my boss ask me the same question in the future. ��

    ReplyDelete
    Replies
    1. But, do you see how the reasons are arranged into BULLETED paragraphs? That's a hint "don't shoot these out all at once".

      Delete
    2. I think a boss needs to see *every* possible reason *every* single time they ask that question until they stop micro-managing.

      Delete
    3. Yep. Flood them with technical details and two hour meetings explaining concepts they take that long to grasp. Make micro-management SO COSTLY for them that they give it up.

      Delete
  2. I have been asked once, how many lines of code do you write in a day?
    Now I am not sure if that question was from that consultant or from Amazon.

    ReplyDelete
    Replies
    1. Between 0 and 1200. I haven't taken an average.

      Delete
    2. If I can write negative 2000 lines, that's a great day :-)

      Delete
    3. on a bad day -> 1000s of lines
      on a good day -> few 10s of lines
      on a great day -> -100s of lines

      Delete
    4. well, playing devil's advocate, it does make some sense when you're developing new software/functionality vs maintaining/bugfixing.

      Delete
  3. Once I spent like whole day on an issue that caused one of our large dashboard pages to act weirdly. While investigating the problem, I found the root cause and I only deleted 2 lines of code. Fixed.

    But exploring, investigating, testing take a lot more time than coding. As you said, programming is not just 'programming all day'.

    ReplyDelete
  4. To me it sounds like you forgot the ”Because the application is too large and complex and the code is hard to reason about”.

    ReplyDelete
  5. Two lines: one to fix the problem, one to update the test case so that the fix is tested... right?

    ReplyDelete
    Replies
    1. I was about to comment the same, but then reading the comments I found it. And I really hope that's the case, otherwise, there is no value added to the software.

      Delete
  6. As someone just out of uni and at a junior job, this comes great, as the first months I was struggling with the simplest of tasks

    ReplyDelete
  7. Just yesterdeay I add a single line of code to fix a bug that took me 3 days to investigate...

    ReplyDelete
  8. We must be paid for finding the problem, not for fixing it.
    We are not doctors...

    ReplyDelete
  9. Thank you very much for this publication, I like both, work on new things and to fix issues

    ReplyDelete
  10. Reminds of this age old tale,

    He was the best machinist in the district, and it was for that reason that the manager had overlooked his private delinquencies. But at last even his patience was exhausted, and he was told to go, and another man reigned in his stead at the end of the room.

    And then the machine, as though in protest, refused to budge an inch, and all the factory hands were idle. Everyone who knew the difference between a machine and a turnip tried his hand at the inert mass of iron. But the machine, metaphorically speaking, laughed at them, and the manager sent for the discharged employee. And he left the comfort of the “Bull” parlour and came.

    He looked at the machine for some moments, and talked to it as a man talks to a horse, and then climbed into its vitals and called for a hammer. There was the sound of a “tap-tap-tap,” and in a moment the wheels were spinning, and the man was returning to the “Bull” parlour.

    And in the course of time the mill-owner had a bill:–“To mending machine, £10. 10s.” And the owner of the works, being as owners go, a poor man, sent a polite note to the man, in which he asked him if he thought tapping a machine with a hammer worth ten guineas. And then he had another bill:—“To tapping machine with hammer, 10s.; to knowing where to tap it, £10; total, £10. 10s.”

    ReplyDelete
    Replies
    1. > Reminds me of this age old tale...
      This is actually the perfect counter-example. The discharged machinist solved the problem in minutes (with the equivalent of 2 lines of code) because he knew what he was doing. Whereas the others would have taken days to understand and fix the problems because they did not know what they are doing.

      Delete
  11. This comment has been removed by a blog administrator.

    ReplyDelete
  12. Agree completely. I have said this often. Sometimes it only takes one line of code but that line of code took a lot of effort.

    ReplyDelete
  13. Also, if they question what you did they're just encouraging bad practices. Next time you might say, screw this, I'll fix the symptom quickly which is what this dimwit wants regardless of consequences.

    ReplyDelete
  14. If it weren't for Omega Prime, we would all know true love.

    ReplyDelete
  15. This comment has been removed by the author.

    ReplyDelete