Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There Are No Bugs, Just TODOs

almad.blog

Post reply on HN
Print view View original

81–90 of 204 posts

Re: There Are No Bugs, Just TODOs

#81

Post by mytailorisrich »

adrianmsmith wrote: post #69

> there should be an algorithm that everybody should agree on. An example may be: > - If there is downtime, it’s the top priority of everyone affected > - If there is an incident, it’s the top priority for an on-call agent > ... Very much agree about this. The trouble with "high priority" and "low priority" etc. is that different people perceive different things as having different urgency and importance. As long as…

"Downtime" as a consequence of an issue is 'severity', not 'priority'. But yes there needs to be a clear and consistent definition of what the different levels of severity mean. This is usually the case because people will quickly notice that it quickly gets messy if everyone makes up their own.

But, as I mention in another comment, severity does not directly map to priority. Something like severity x frequency (classic measurement of risk) is already getting close, but ultimately it is often a judgement call based on other business considerations as well.

Re: There Are No Bugs, Just TODOs

#82

Post by randomdata »

Almad wrote: post #58
gitgud wrote: post #52

Github issues works pretty well for almost all software projects. A single list of issues viewable/searchable by the whole team, simple commenting, code referencing, tagging, assigning to people. We tried Jira but became tangled in a mess of complex configuration and endless confusing UI's...

The main problem I had with them is inability to sort them in a list, which is somewhat solvable with GH Projects now.

For most projects, sorting leads to prioritizing, which is an anti-pattern. For those who choose to eschew proper software development practices, it is nice that Projects is its own thing.

Re: There Are No Bugs, Just TODOs

#83

Post by kazinator »

The Software Version field should be used to identify the commit when the bug was introduced (perhaps the very first commit that introduced the entire thing in which the bug is found or perhaps a regressing commit). The way it's typically used is not helpful: namely that the user who reports the bug just fills in the version they happen to be running when it happened.

There should be an Introduced-in Version and Fixed-in Version.

Re: There Are No Bugs, Just TODOs

#84

Post by JamesSwift »

mytailorisrich wrote: post #81
adrianmsmith wrote: post #69

> there should be an algorithm that everybody should agree on. An example may be: > - If there is downtime, it’s the top priority of everyone affected > - If there is an incident, it’s the top priority for an on-call agent > ... Very much agree about this. The trouble with "high priority" and "low priority" etc. is that different people perceive different things as having different urgency and importance. As long as…

"Downtime" as a consequence of an issue is 'severity', not 'priority'. But yes there needs to be a clear and consistent definition of what the different levels of severity mean. This is usually the case because people will quickly notice that it quickly gets messy if everyone makes up their own. But, as I mention in another comment, severity does not directly map to priority. Something like severity x frequency (clas…

I think you misunderstood his point. He is saying that in his system severity == priority. His article he linked lists out explicitly his buckets.

Within a given severity I think its then a judgement call of a product owner to rack-and-stack the issues in priority order, exactly how it would be done for traditional 'P1' - 'P5' grading.

Re: There Are No Bugs, Just TODOs

#85

Post by adrianmsmith »

mytailorisrich wrote: post #81
adrianmsmith wrote: post #69

> there should be an algorithm that everybody should agree on. An example may be: > - If there is downtime, it’s the top priority of everyone affected > - If there is an incident, it’s the top priority for an on-call agent > ... Very much agree about this. The trouble with "high priority" and "low priority" etc. is that different people perceive different things as having different urgency and importance. As long as…

"Downtime" as a consequence of an issue is 'severity', not 'priority'. But yes there needs to be a clear and consistent definition of what the different levels of severity mean. This is usually the case because people will quickly notice that it quickly gets messy if everyone makes up their own. But, as I mention in another comment, severity does not directly map to priority. Something like severity x frequency (clas…

I must confess I've never really understood the need for "severity" in a task tracking system.

As far as I can see, consumers of tickets need to know what order to do stuff in, and producers and organizers and curators of tickets need to set what order things should be done in. That's "priority" or "urgency".

I do understand in a theoretical sense that "Prod system is down" might not always be the absolute highest priority thing to work on. If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on.

But that's a theoretical example. In my 20 years of software development and managing projects, if the Prod system is down, it's an emergency, and that's what you need to be working on. So "Prod is down" is a useful priority/urgency. At least that's been my experience so far...

What am I missing? Are there times when priority and severity are useful as two separate fields?

Re: There Are No Bugs, Just TODOs

#86

Post by uxamanda »

Nice, this highlights a lot of issues I’ve seen with teams and crazy bug systems.

One difference I had from the article is that I actually find marking tickets with priority and types (like bug / enhancement etc) useful, but for a different audience.

When I’m working on planning / strategy, aka in Product Manager mode, I like to be able to review what is still remaining in different buckets and adjust priority and do scenario planning. Maybe it’s worth closing a whole bunch of low priority bugs before moving on. Often the priority changes over time and gets adjusted as we see what came in. Having a place to track that info on the ticket keeps me from moving to doing planning in a spreadsheet.

When I’m in developer mode, I agree - I don’t want to have to think about what the priority of a critical feature improvement is vs a low priority bug. I want to pick off the top of the stack and flow with confidence.

I often am working in both roles on team projects and use this technique even when working alone.

In my experience where things get weird is when the product planning metadata is required to be understood in real-time by all roles on the team. You can keep all that metadata around and still have a single prioritized backlog.

Maybe Jira could be improved by showing different metadata for different modes... but even writing that out sounds like a new configuration nightmare!

Re: There Are No Bugs, Just TODOs

#87

Post by twic »

ydlr wrote: post #54
twic wrote: post #39

Earlier quoted context omitted.

There may be a similar legibility point about severity levels. Some boss somewhere has to put the set of tasks in priority order for the development team, and once it's in that order, severity levels are useless for the developers. But they might be useful as a way for the person submitting the issue to communicate something to the boss who does the ordering. Say there's a billing system. One of the accounts receivab…

Why not have the clerk assign the severity? Why can't the programmer and clerk discuss the problem themselves if there is uncertainty? The only problems in your scenario arise from the introduction of a boss as go-between.

I am proposing that the clerk should assign the severity.

You could have the programmers do the prioritisation, if they had the business understanding to do that. In that case, they're also the boss. The severity assigned by the clerk could still be a useful starting point.

Re: There Are No Bugs, Just TODOs

#88

Post by kazinator »

barbegal wrote: post #18

> There is one good argument in its favor [closing tickets that are too old]: the software continuously changes and hence old issues may be invalid. In order to put them into a sprint, they need to be checked—in some cases, that’s actually more work than the issue itself. I agree this is sometimes true, those difficult to reproduce tickets often mysteriously disappear when you make other changes. But there are lots o…

A bug should identify where it was introduced. If a bug was introduced in version 0.5, then version 0.5 forever has that bug, and so the issues is forever valid in that sense, as a truthful comment about a historic thing. If the current version is 1.2, and it has not been confirmed to have fixed the bug, the view should be taken that the bug still exists in 1.2. Bugs don't just become invalid; if we are justified in calling a bug invalid now, that can only be because it was never valid in the first place.

Suppose that someone tries to check, but the bug doesn't reproduce in 1.2. However, it was never root-caused. All we have is a description of the behavior that was happening in 0.5.

Now what? Do you just close that bug to get the open bug count down?

Probably an "unsolved mysteries" or "cold cases" category would be more appropriate for it rather than lumping it with genuinely closed bugs: those that were traced to a root-cause and confirmed.

In cases when you're sure that the bug was due to some software that was entirely rewritten such that the same bug cannot plausibly be in the rewritten version, or some software that was removed entirely, then there is justification in closing that.

Re: There Are No Bugs, Just TODOs

#90

Post by aflag »

randomdata wrote: post #82
Almad wrote: post #58

Earlier quoted context omitted.

The main problem I had with them is inability to sort them in a list, which is somewhat solvable with GH Projects now.

For most projects, sorting leads to prioritizing, which is an anti-pattern. For those who choose to eschew proper software development practices, it is nice that Projects is its own thing.

I don't think that prioritizing in general is an anti-pattern. You will do things before other things and you need to choose what to do first. The criticism in the article was about bad prioritization. With GH Projects you can have the liberty to queue issues however you may see fit.
Post reply on HN