Is My Bug for Developers or Product?

We all know the situation, right? We find an “issue” but in many cases it comes down to determining whether our issue is something for the developers to fix or if it’s something for product to clarify. It’s often a question framed as “Is this a bug?” Hidden within that question is dealing with the protean nature of a “bug” in current software development.

For the sake of argument, let’s say we all agree that a bug is anything that threatens value. That one statement alone, if accepted, can change some perceptions about bugs. Value, of course, is based on perception and while some perceptions will be objective (“It crashes!”) others will be subjective (“It performs slow” or “It looks ugly” or “The workflow is complicated”). Sometimes the subjective can become objective based on shared agreements.

Consider one of the areas that are often problematic: so-called “edge cases.” There are actually three things to consider that usually get lumped under one term: edge cases, corner cases, and pathological cases. It can be helpful to know which one we’re dealing with. Sometimes an “edge case” can be easy to dismiss but, in turns out, it’s really a boundary case — and those should be less easy to dismiss.

For example, if an agreed upon boundary violation is happening, that’s likely a bug for developers. If there is a question as to whether the boundary even makes sense (perhaps it should be higher, perhaps it should be lower), that’s probably a bug for product. It needs to become a decision that is captured as part of our acceptance criteria.

As another example, if a true edge case manifests a problem, then it becomes a joint decision of product and development: priority (how important to business, given the likelihood) and severity (impact if the situation happens). Let’s say something is very unlikely. But … if it happens, we could end up with a corrupted database. Priority may be low but severity may be high.

So we have a few issues to unpack:

  1. What do we consider bugs?
  2. What are our heuristics for recognizing bugs?

Consider these various possibilities:

  • “I know this is a bug because it causes a 404 to display.”
  • “I know this is a bug because it’s not what our acceptance criteria says.”
  • “I know this is a bug; I agree it matches the acceptance criteria, but it’s compromising one of our qualities.”
  • “I think this is a bug because while it matches our acceptance criteria, I think the criteria are wrong.”
  • “I think this is a bug but we don’t have acceptance criteria one way or the other.
  • “I think this is a bug because it just seems like the workflow is really complicated.”

There are obviously other variations there. The regression one is usually obvious:

  • “I know this is a bug because it was working before and now it’s not.”

I’ll leave out the complication for now of where the “bug” as it is working now is actually the correct functionality and how it was working before was actually incorrect. That said, it is worth noting that this can happen. Specifically, a bug persists for so long that we just start to treat it as “how it all works.”

The point being there are times where we “know” it and “think” it. Sometimes what we consider a bug (value threatener) serves as the impetus for a feature request. That can come from us or from our users.

What we do want (I hope) is this: we want the time between when a bug is introduced and when a bug is found to be as short as possible.

Many of our bugs will creep in before we even code, must less deploy. That can be for many reasons perhaps we were short-sighted in our design thinking (intentionally or otherwise); perhaps we didn’t know about technical constraints at the time decisions were made; perhaps we had a faulty view of a user model and thus a usage pattern.

Once we have implemented (but prior to deploy), what we’re looking at is deviations from our acceptance criteria. Questioning whether the acceptance criteria are valid in the first place is totally viable — but if we’re finding a lot of issues like that, we need to put more of the test focus where those issues are being created.

Whether pre-deploy or post-deploy, it’s important to determine the kinds of bugs we’re dealing with. For example, what about transient or intermittent bugs? Those are often the hardest to reproduce, much less isolate. That can be because the bug is dependent on time or specific data or other variables.

We also have internal qualities we might want to consider. What if we are, during implementation, knowingly degrading one of our internal qualities? Perhaps, for example, we are doing something that will raise the number of Postgres connections, which might eventually lead to a degradation in performance. Clearly a developer bug, right? Okay, but what if we’re doing that because a feature desired by product has a technical constraint that will require these connections? Now we have a technical constraint that needs to inform a product decision.

“But is that a bug?”, I hear someone asking.

Well, if we treat a bug as something that is threatening value, then yes, quite possibly it is.

Share

About Jeff Nyman

Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words. If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Is My Bug for Developers or Product?

  1. Johan Hoberg says:

    The point being there are times where we “know” it and “think” it. Sometimes what we consider a bug (value threatener) serves as the impetus for a feature request. That can come from us or from our users.
    The point being there are times where we “know” it and “think” it. Sometimes what we consider a bug (value threatener) serves as the impetus for a feature request. That can come from us or from our users.

    I think you have accidentally added the same paragraph twice. Or something is wrong on my end.
    Interesting article and many great points.
    Best regards,
    Johan
     

    • Jeff Nyman says:

      Indeed so. You are correct and I thank you for bringing that to my attention. Bug report accepted and corrected!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.