5 ms·

Because a crash is different than a button rendering with the wrong color, and although priority assessment might change with time, a crash is still a crash. I

Because a crash is different than a button rendering with the wrong color, and although priority assessment might change with time, a crash is still a crash. It seems that a recurrent theme in this thread is that some developers have a hard time understanding that PMs might have solid reasons to prioritize low-severity issues over high-severity issues. It's like these developers are stuck with a mindset where the forest doesn't exist and only the trees they personally have direct contact with should.be worth any consideration.

daveFNbuck 7y ago
Why set a severity if you're not going to use it? A crash is still a crash if you don't set the severity and just write that it's a crash in the bug description.
- FemmeAndroid 7y ago
  So the PM can triage high severity issues quickly, because even though they may be p2 issues they’re probably worth serious consideration.
  - wpietri 7y ago
    I know some people look at me like I have three heads every time I say this. But if a project is dropping so many balls that it's hard to keep track of them all, I think the real solution is to work smaller and close feedback loops faster, so the sheer number of bugs is not overwhelming.
    - doingmyting 7y ago
      Have you worked at small companies all your life. There are teams with 50 devs in some places and shipping huge multi-hundreds of million dollars pieces of software that is in a lot of cases, legacy software. You dont get a call in deciding to work smaller with closed feedback loops all the time. Your opinion on this strikes me as you being a junior in the software dev world.
- rumanator 7y ago
  > Why set a severity if you're not going to use it? Your question misses the point entirely. The point is that severity is an element that's used to classify an issue with regards to priority. Severity does not exist in a vacuum, and priority is given depending on context. Severity is an attribute, other attributes, that's used to determine the priority.
  - wpietri 7y ago
    It's only used to determine it in a way that's divorced from the business context. If everybody understands the business context, that's no longer useful. Ditto if people are collaborating with actual discussion, rather than trying to mediate communications via a database.
    - rumanator 7y ago
      > It's only used to determine it in a way that's divorced from the business context. If everybody understands the business context, that's no longer useful. That's the point, everyone does not understand the business context. Nor are they expected to. That's the job of the PM it's his main responsibility, and it's the reason PMs are hired to manage teams of developers.
      - wpietri 7y ago
        I understand some organizations work that way. I'm saying it's bad. The point of developers is to make software that people use. So if we want to do our jobs well, we have to understand how we are creating value. Product managers may manage that information flow, and they may get the final say in decisions. But if they are specifying software in enough detail that developers can be 100% ignorant, then developers can (and should!) be automated out of that work.
  - daveFNbuck 7y ago
    What extra context does "severity 0" give you on top of a bug title like "Site crashes on action X"?
perl4ever 7y ago
I think this thread is interesting and kind of funny, because it reminds me of work where I maintain some systems that keep track of projects for PMs, and I originally thought my job was to make everything consistent. But there are a whole slew of ways to express the "closedness" or "openness" of a project, and the PMs have evolved conventions where they want to be inconsistent and resist all efforts to make it all make sense. You have a project status which may be in progress or closed or something else. You have a closeout milestone which may be in progress or closed or something else. And you have a time entry code which may be open or closed. But it turns out there is no simple way to make these consistent, because people use inconsistent combinations to express things...but it's hard to tell what.

daveFNbuck 7y ago

Why set a severity if you're not going to use it? A crash is still a crash if you don't set the severity and just write that it's a crash in the bug description.

FemmeAndroid 7y ago
So the PM can triage high severity issues quickly, because even though they may be p2 issues they’re probably worth serious consideration.
- wpietri 7y ago
  I know some people look at me like I have three heads every time I say this. But if a project is dropping so many balls that it's hard to keep track of them all, I think the real solution is to work smaller and close feedback loops faster, so the sheer number of bugs is not overwhelming.
  - doingmyting 7y ago
    Have you worked at small companies all your life. There are teams with 50 devs in some places and shipping huge multi-hundreds of million dollars pieces of software that is in a lot of cases, legacy software. You dont get a call in deciding to work smaller with closed feedback loops all the time. Your opinion on this strikes me as you being a junior in the software dev world.
rumanator 7y ago
> Why set a severity if you're not going to use it? Your question misses the point entirely. The point is that severity is an element that's used to classify an issue with regards to priority. Severity does not exist in a vacuum, and priority is given depending on context. Severity is an attribute, other attributes, that's used to determine the priority.
- wpietri 7y ago
  It's only used to determine it in a way that's divorced from the business context. If everybody understands the business context, that's no longer useful. Ditto if people are collaborating with actual discussion, rather than trying to mediate communications via a database.
  - rumanator 7y ago
    > It's only used to determine it in a way that's divorced from the business context. If everybody understands the business context, that's no longer useful. That's the point, everyone does not understand the business context. Nor are they expected to. That's the job of the PM it's his main responsibility, and it's the reason PMs are hired to manage teams of developers.
    - wpietri 7y ago
      I understand some organizations work that way. I'm saying it's bad. The point of developers is to make software that people use. So if we want to do our jobs well, we have to understand how we are creating value. Product managers may manage that information flow, and they may get the final say in decisions. But if they are specifying software in enough detail that developers can be 100% ignorant, then developers can (and should!) be automated out of that work.
- daveFNbuck 7y ago
  What extra context does "severity 0" give you on top of a bug title like "Site crashes on action X"?

perl4ever 7y ago

I think this thread is interesting and kind of funny, because it reminds me of work where I maintain some systems that keep track of projects for PMs, and I originally thought my job was to make everything consistent. But there are a whole slew of ways to express the "closedness" or "openness" of a project, and the PMs have evolved conventions where they want to be inconsistent and resist all efforts to make it all make sense. You have a project status which may be in progress or closed or something else. You have a closeout milestone which may be in progress or closed or something else. And you have a time entry code which may be open or closed. But it turns out there is no simple way to make these consistent, because people use inconsistent combinations to express things...but it's hard to tell what.