> Having bucketed priorities (highest/high/medium/low/lowest) is a big failure of Jira / ticketing systems though. They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.

Jira supports both. The thing you're describing is called Rank and is used on every board and backlog. Our team uses Rank almost exclusively. The bigger thing to understand here is that different people use different "labeling systems". If you ignore software dev and think about note taking, there are a bunch of different systems. Some work better for one group of people, others work better for another group. I think Jira has had a lot of success because it doesn't force people into one system. The downside is that people often configure it to use 3 different systems at the same time and they vary team to team and this causes a lot of strife and confusion.

This is the most logical, sensible comment in the thread. Jira is the most flexible system for workflow management in existence. The fact that it is extensible is "a feature, not a bug."

I don't see really see anyone stating obvious truths about bad developers & software engineers (as shocking as it may be to read on HN that there are, in fact, objectively bad developers & software engineers with high-paying jobs at companies whose names you know.)

- they are more interested in making a new thing instead of fixing a broken thing they released

- they often can't remember how they built the last new thing

- that's because they aren't interested in building & documenting a fully working thing with test code from the start

- they aren't interested in data structures or architecture built to be easily maintained or in making scale part of their designs

- they despise being told to fix bugs because it is much easier to write code than it is to read it

I believe some organizations implement Jira thinking it is going to solve their cultural problems. This is magical thinking.

I am so tired of hearing about how terrible Jira is from developers.

It's usually the case that where Jira isn't working it has to do with the way it's configured (e.g., giving too many people access to set priority, setting too many priorities, setting too many components, using components in illogical ways, no one actively managing & grooming queues...)

To implement Jira successfully probably requires more work & effort to get it right than to not use it at all. The point of it is not to eliminate the work of issue tracking. It is to organize the workflow management of moving incredibly complex information from one person to the next. It's pretty great at this if you know how to use it.

I completely agree and I hope I explicitly mentioned it in the article: it's not Jira, it's about how people/organizations often think about the problem.

I love the restaurant analogy - it has great resonance especially if you consider cost of making it right.

If I order a Lasagne and get spaghetti meatballs, i think that's a big and i expect to be fixed.

If I order Lasagne and get Beef Lasagne when Inamna vegetarian then I still think it's a big, but the failure is not immediately in the kitchen - why did the waiter not check, if I am wearing dungarees and a a Tee Shirt saying "Die all meat eaters" should that be a clue?

And what about the kitchen response - we all like the restaurant that apologises and comps the food for free. But we would be a bit surprised if we were told the Beef Lasagane was not going to be refunded and we had to pay again to get the veggie one.

But all those models exist in software.

I like the analogy. I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements. Either the requirement wasn't specified well or a change of circumstances requires it to work differently. In either case, it's a request for modification not a bug. Your analogy should help me explain the difference.

The user doesn't care whether the bug is in the requirements or if it's in the code. They just know that it's not working for them, and want it changed.

Arguing that it's not a bug seems like saying 'not my problem' to everyone else. I expect different companies have different cultures around assigning blame that might make saying 'not my fault' important, but I'm pretty sure that customers/users don't care one bit about that.

Whether it's a bug or a modification to requirements I'm still the one who works on it. So "not my problem" doesn't exist in my situation. The distinction matters very much when it comes to prioritizing my work. I'm 100% time on projects and jump from one to the next with no pause between. I'm also the only developer who supports the apps I built. Bugs usually jump to the top of the queue. Management puts a lower priority on requests. In order to not hurt my current "customer", I need to make sure past ones don't try gaming the system by declaring bugs when they're not.

It is very common for companies to forget how to properly prioritize between bugs and features. Trying to reinforce this by trying to teach them how to correctly (according to person on internet) classify bugs or features still sounds like a complete a waste of time.

Right, to the customer it doesn't matter (just like to the developer it doesn't need to matter either - it just means the work needs to be performed).

However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.).

Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.

there's a -- critical -- feedback loop problem that you're ignoring. sure, you might work on it with the same priority regardless of characterization. but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.

> but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.

For a few companies, sure. The chance that he's working on one of those is zero (based on what he has written so far).

> I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements

Oh no.... You are wasting yours and theirs time. This is such a developer thing to do.

Please see my comment to allanniehuis.

Don't confuse the waiter with the customer.

If the waiter gets the request wrong from the customer, it's still a bug. Even if the kitchen does exactly what was in the waiter request.

It's a team effort.

I find it useful to differentiate bug from feature because they have a very different information set associated with them. Bugs need to provide description, steps to reproduce, expectation, observation, workaround and are require a write up as part of their completion (root cause). Features, on the other hand, need only a requirements list.

I do agree completely on "failed promise" and this is actually why I think the bug vs feature is flawed. I think "failed promise" is a great ticket type though ;)

There are obvious cases where I have nothing against what you say. But to use the analogies, "I thought the food would take differently and I don't like this one" is the more common type and it's the one that's murky to resolve.

The point here is that regardless of the reason, you want to tend to "customer is not happy" case.

As a developer, I generally find having a distinction between bugs and features useful.

If I'm going to do a big refactoring of some component, I find it useful to look for related open bugs (even if they're low severity) because sometimes it's low or zero extra effort to fix them at the same time. This only works if you have good quality tickets though (proper tags, alias words, etc), which is a whole different topic.

I think it also reduces cognitive load while looking at tickets to have them categorized that way too. Of nothing else being visually distinct (via icon or something) just makes it easier to process.

Above all though, it's important not to argue about bug vs feature. Ideally any bug can link to the feature ticket that isn't working, but either way it's more important to make things better for the customer, so if that means considering a what is really a feature request a "bug" because it'll cause a big argument otherwise, then do that.

> They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.

I've heard the ability to drag & drop tasks around in an ordered list (i.e. a task only has priority relative to others, i.e. it's position in the list) as "ordinal priority".

I don't know that I've ever seen a feature that wasn't some sort of "failed promise". The feature sometimes hits and sometimes misses, and is usually somewhere in between. This idea that a defect is a failure of a feature is probably more to do with the inability to predict the future. Sure there are defects like you tried to read from /dev/null, but more realistically the "defects" you see today are more about the inability to predict exactly how a feature is going to be used.

Yup - from a implementation perspective, bug vs feature is a artificial designation.

Where I think it _does_ matter, is when a business wants to track metrics like "# of bugs over time" or "# of bugs per feature".

My team recently got a lot of heat about "a rising number of bugs", and the insinuation was that our code quality was poor. Turns out, > 75% of the "bugs" reported were mis-labeled feature requests or lack of knowledge about how a particular feature was designed to work.

Whoever is giving your team heat about bug metrics needs to read about Goodhart's Law.

There's so many ways to influence number of bugs that it's pointless to measure anything that way. For example, do you make a single bug that lists 15 typos spread around, or 15 bugs (because after all, each typo is a different word and in a different part of the app). Do you accept vague but obviously real bugs while you try to collect enough info over time, or immediately close them as "cannot reproduce"? Is that a bug, or really a feature request?

One way the distinction gets used where I work is to have custom / required fields keyed on the ticket type.

Oh, you want to make a bug ticket in my project? In that case, required fields include "steps to reproduce", "expected result", and "actual result". You want to make a feature ticket in my project? In that case, required fields include "rationale" and "acceptance criteria".

Earlier this year, I reported a bug in Firefox. In my report, I included steps to reproduce the issue, the expected result and the actual result (because I've been on the other side). There were no back-and-forth messages to clarify the issue, and it was fixed in a short amount of time (well, short for a project of that size).

But you have to acknowledge some features are bugs.

For example, if you have a word processor, having a running word count sounds like a feature.

To a developer it seems frivolous, like having a LOC counter.

But to people who write professionally word count might be the most critical metric of all (like a progress bar for "article is done")

just saying... failed promises