Hacker News Reader

Comment by rumanator | Hacker News Reader

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.

View on HN

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.

So the PM can triage high severity issues quickly, because even though they may be p2 issues they’re probably worth serious consideration.

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.

> 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.

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.

> 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.

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.

What extra context does "severity 0" give you on top of a bug title like "Site crashes on action X"?

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.

Reply on news.ycombinator.com