Hacker News Reader

> I'm really confused by all this arguing against simply having more information.

As with all information gathering, you need to weigh the cost of gathering and storing vs the gains of having the information.

People are saying there are no gains from having this information; which, if true means if there's any cost, the cost is too high.

People are saying it is hard to determine, which means the cost to gather it is high, it may include concensus building.

In my personal professional experience, there hasn't been a whole lot of retrospective analysis on the bugtracker data. So information gathering that doesn't immediately help with fixing the bugs, or communicating which bugs need to be fixed sooner is time wasted. Use of non-critical fields in the tracker is spotty and inconsistent, so analysis would require an expensive data cleaning phase.

Sure, you can say I didn't work in healthy organizations if they didn't do this sort of analysis. But that's the root cause of most of the bugs --- there were never any formal specifications and so many things didn't meet the specs; plus occasionally we wrote crashy code.

> I'm really confused by all this arguing against simply having more information.

What people are pointing out is that you're not arguing for having more information. The "severity" is a marginal zero information on top of the priority. There is no context where you would want to use "severity" instead of priority.

So...

GIVEN that priority trumps "severity" 100% of the time,

AND GIVEN that priority is already being recorded,

THEREFORE "severity" has no use, and shouldn't be recorded.

What's happening in the post is that someone wondered why there were two fields, and made up a justification for the second field instead of realizing it was a mistake to have two.

You can see the mistake happening whenever people choose a word that ordinarily refers to the concept of importance as their label for "severity", while simultaneously acknowledging that "severity" doesn't affect the importance of the issue.

They're saying that severity informs the decision of how to set priority. I'm not sure why that's necessary since severity is implicit in the description of the bug.

How is severity supposed to inform the decision of how to set priority? That decision is determined by business needs, not "severity".

As I said above

> In some cases the criticality is relevant to the business decisions, in others it may not be. It probably usually will be. The app shouldn't crash, because even if it only happens to 1% of people, they're the ones writing reviews on the app store.

> So the criticality is a big red "Hey! This should probably be high-priority!"-flag, but it's not the only piece of information the PM is going to use.

The point is that PM may be inundated with lots of bugs and new features and other stories that all need prioritization before the next release. If they had a perfect understanding of all of them, they wouldn't need any metadata at all (not even "bug" vs "feature" -- just read the long-form description!), but metadata helps people make decisions.

High-severity bugs should generally be prioritized higher, except in cases where PMs have gained a deep understanding of the situation and realize it's not business-critical, and override that.

At the point that they set the priority, the criticality is no longer important, just as the "bug" vs "feature" tag is no longer that important once it's been prioritized and assigned.

> I'm really confused by all this arguing against simply having more information.

I think the argument is that it's not actually more information; it's just smearing out the same information in a way that makes communication and decision making harder. (Note I'm not completely convinced by either side here, just trying to explain.)

> Yes, of course: "When I press the 'more' button in the developer's bio the app crashes" is a more important bug than "When I press the 'more' button in the developer's bio I don't see more text."

Of course? Really?

I mean, the upshot for the user is the same - they wanted to see more info about the developer, they clicked the button, they didn't see more info.

An app crash on most devices isn't actually a particularly dangerous problem. Start the app up again.

Arbitrarily deciding that a particular bug is worse because it causes more harm to the software rather than because it causes more harm to the user is precisely the problem. The importance of fixing those two bugs is probably exactly the same (unless the app crashing causes data loss or corruption or is exploitable or... you get it. Of course, the same could be true of the 'no more info appears' bug - behind the scenes it might be starting an infinitely retrying string of HTTP requests to download the developer bio that gradually leak memory and drain the user's battery. Maybe that's really the more serious bug?)

There isn't some separate measure of 'severity' that independently makes the crash bug magically worse than the functional failure. There's only the actual consequences of the bug. For the user, their data, their time their resources, and your business goals.