Hacker News Reader

Comment by Chinjut | Hacker News Reader

The person you are responding to is saying, yes, "cosmetic stuff" might be far more important. So it's more important! Why have another dimension of assessment where we label it less important? Why not only have the dimension of assessment that actually matches the clients' needs?

View on HN

Like I said in my other comment, because it makes the difference between controlled and uncontrolled.

Eg "the color is wrong because we specified it wrong" and "the color is wrong because the app doesn't respect what we ask it to display" both ends up with the same bug (wrong color), same priority, but not the same severity because the second case is uncontrolled.

Severity is a dev tool, priority is a business tool.

How does setting a higher severity for one bug over the other help devs?

How would you signal the difference between:

1. We have the wrong .png asset in the database

2. Our entire rendering infrastructure is suspect

That would be extremely obvious from the bug title and description, which are presumably being read by the person who sets priority.

So instead of a severity rating, you are saying severity is encoded in the language of the description? Using descriptors a potentially non-technical PM can understand unambiguously?

I'm not saying this is the wrong approach by the way, it's just interesting how people approach this differently.

If the PM doesn't have enough expertise to understand how severe a bug is, how are they supposed to accurately assess the business impact?

It's not another dimension. It's a classification. Some issues matter more from one perspective but might not justify allocating resources to address them from other perspectives. To be able to do an adequate job prioritizing issues, you need to take in consideration their classification. You're arguing about a desired outcome without paying any attention to the process that leads you to that outcome.

Because there is expressed client needs and real needs. They say they care about this cosmetic thing now so it better be fixed. However you well know that if you don't get this other thing fixed soon internal politics at the client will mean they throw you out. Thus you fix the thing they demand be fixed now (it may only take a few minutes), but you ensure the other things are fixed in the next release even though the client doesn't know they care yet.

Sure, but you don't need separate priority and severity scales to do that: it's just one priority scale but you just assign the priority not entirely on the clients expressed needs but rather also factoring in your own assessment of their needs.

You don't need that, but you are not everybody. When you have a large organization having a simple way to capture this type of thing and make it clear what you are talking about matters.

Of course it does add complexity. It is the call of each organization which things are important enough to be worth the extra complexity and which are not. Maybe for yours it isn't worth the extra cost - there is nothing wrong with that - but other people have different needs and so they will have different answers.

In short, you are wrong in thinking there is a universal right answer.

Reply on news.ycombinator.com