6 ms·

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

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"?

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"?