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.


44 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
    4. A good leader of a programming team understands it very well, I guess. I'm aware there are other leaders ;)

      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
    5. I agree with Unknown - the best days are the ones where the amount of code decreases. Nothing beats that feeling. Sometimes you have to write a lot of code to get to that point though. As you code, you're exploring the problem, you might write a hundred lines, and then delete it all and replace it with two.

      Delete
    6. When developing new software/functionality I would rather have someone who can write readable and tested code rather than someone who can write REAMS AND REAMS of code that isn't as readable. Counting lines is never the answer. Software is never done, so when I come back to some years old code it had better be easy to dive back into and well tested.

      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
    2. We all like tests, but saying there's no value added by fixing bugs (without tests) is ridiculous. Do you think customers agree?

      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
    Replies
    1. I once fixed a bug that involved adding the word "static" to a file. The problem had seriously disrupted a large team for weeks, costing many thousands, and the guy who introduced the bug was mortified, although he it was a mistake anyone could have made. What I took away from it wasn't really about individuals - the processes that the company had didn't allow them to find bugs in a timely fashion, and it cost them a lot of money.

      Delete
  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
  16. I moved code to fix a bug so I win

    ReplyDelete
  17. I am reminded of this anecdote: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt

    ReplyDelete
  18. i have been developer 10 years and 10 years CIO

    Let me explain you in easy words:

    1. If you expert take 2 days in resolve how much days will take a junior or new employee? is really (bad the code created right?
    2. If you expert take 2 days and dont think is weird... next time may be is 3 or 4 days? none in this company know how to comment code to make easy to resolve?

    In summary if you write a code a any employee take 2 days to modify, change or ammend is really bad, company dont need gurus with 2 lines magics none can work with... they need easy, fast and productive lines to continue all working easy, fast and productive.

    Imagine any tube in your home the plumber take 2 days to undestand and will charge 2 full days work any time you call him... you will be happy? but you expect your manager is happy?

    ReplyDelete
  19. I'm gonna save this and give it to any business/management person that asks why something took so long. Thanks for the write up.

    ReplyDelete
  20. Great write up. Anyone who has worked on a older or legacy system will have been in this situation. Saving this for future reference!

    ReplyDelete
  21. good stuff
    I've bookmarked it and now I'll just send the link to avoid having this discussion again.
    Thanks for putting into words what we all feel.

    ReplyDelete
  22. Sometimes, very small mistakes can have big consequences...

    Mars explorers that burn up on entry. Multi stage rockets, where one stage was built by a different contractor - and metric measurements didn't quite match imperial.

    But my all time favorite remains - the satellite that missed a period.
    Satellites have a limited fuel supply, and no way to refuel. So orbital corrections are few, and short. One controller received a message for an orbital correction burn of 1.5 seconds. Sadly, the printer (which rather dates this story) did a poor job of printing the decimal point, AKA full stop, AKA period.
    The result was a FIFTEEN second burn which took the satellite WAY off course. Getting it back used up most of the remaining fuel, and the lifespan of a multi million dollar product was significantly shortened.

    From that time on, all orbital corrections gave burn instructions in words, ie. "one point five seconds".

    ReplyDelete
  23. "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."
    That's just wasteful, like driving aimlessly around when you're lost instead of asking for directions. Unless you think a few hours of your time isn't worth as much as a couple of minutes of the time of the person who under-reported the problem.

    ReplyDelete
  24. If you added only two lines of code that means you did not add a test to reproduce the error and avoid regressions

    ReplyDelete
  25. Nice article, thx =)

    ReplyDelete
  26. "Well, I could have fixed it in one day, but it would have taken 25 lines of code"

    ReplyDelete
  27. "Because the issue was reported with a vague description of how to recreate it."

    Perhaps this depends a lot on who reported it.

    But if they could've given enough details with 5 extra minutes, and you're spending 5 hours to save them 5 minutes, maybe your boss is right to blame you?

    ReplyDelete
  28. Thanks for the post - as well as being a good explanation to managers etc. this is also a great reminder to engineers of the level of care and attention that should be paid when maintaining code.

    ReplyDelete

Note: only a member of this blog may post a comment.