1. 9
  1.  

  2. 4

    Relevant XKCD

    I’m torn on this, it’s very much a case-by-case thing. Relevant questions to ask include:

    • Is there a reference which states that you are not allowed to rely on the bug?
    • How many people depend on the bug?
    • Is it a security issue?
    • How important is backward compatibility in this case?
    1. 1

      I think the existence of a reference saying you can’t rely on a behavior is a very weak signal. It appeals to the part of our minds that wants to assign blame for a situation, but it doesn’t really change the consequences of changing the behavior.

      “I told you not to do it, you did it anyway, now I’m stuck supporting it” is a perfectly pragmatic viewpoint. So is “I never talked about it, you relied on it, but I’m going to change it because it’s terrible”.

    2. 3

      Of course the gotcha where this logic goes wrong is fixing a bug that someone is depending on hurts that person, briefly.

      However, quite likely the pain is temporary and the bug will hurt new people time and time and time again for the lifetime of the product, ultimately until someone comes up with a less buggy product less burdened with bugs and technical debt and obsolete misfeatures.

      And then suddenly lots of people take that one hit pain and jump anyway…

      1. 2

        I’m not opposed to the author’s viewpoint that systemd did the wrong thing, but I disagree with the statement that it’s wrong to call a behavior users rely on a bug. I think the right perspective is that sometimes there are bugs you cannot fix.

        Maybe that’s nitpicking over the meaning of words, but I think it helps focus attention on the ways that our software falls short of what it could be. Acknowledging that these bad behaviors exist makes us understand that we are choosing not to fix them. Our reasons for not fixing them may be valid, but they are a decision, and one which should be made with a focus on both the short-term and the long-term consequences of that decision.