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

161–170 of 204 posts

Re: There Are No Bugs, Just TODOs

#161

Post by sethammons »

ehnto wrote: post #91
dataduck wrote: post #31

Earlier quoted context omitted.

This seems interesting but I'm having trouble visualising it. Would you care to elaborate?

Sure! A standard ticket pipeline might look like this: Backlog > Review/Estimate > In Progress > Internal Review > Testing > Client Review > Feedback > Testing > Release But the rapid pipeline will be more like: Create Ticket > In Progress > Testing > Release This leaves the ball almost entirely in the developers court, and removes any step that requires waiting for feedback from the client or even the Project Manage…

That is how all our tickets work. We have a lot of autonomy in that regard, put the product owner still sets the priorities

Re: There Are No Bugs, Just TODOs

#162

Post by ludston »

VBprogrammer wrote: post #34
thombat wrote: post #6

Earlier quoted context omitted.

Our company became determined to control such panic-driven prioritisation, and had four simple levels of importance, P4 up to P1, a predictable conveyor belt delivering work. Equally predictable was the later addition of P0. Followed inevitably by P-1. Sadly the company was bought out before we learnt whether the underlying datatype was a signed short or a long...

That is so familiar that I seriously wondered if we had crossed paths at a previous job. The only difference being our priority was the other way around P4 being the highest. Basically all tickets would naturally migrate to P4. Eventually when someone started working on 'the wrong thing' another level was added. In my current job we use Jira and the backlog has things at the bottom which have been just added, things…

We've been doing that for a few years now. Basically we have two queues: The queue for escalated defects, and an ordered queue of about 10 prioritized enhancements that we've ordered based on what we think is most important comparatively. There is also a backlog of ideas/garbage work.

It works fine, except that the product is complex and old enough (and the team has too few developers so) that the bug queue rarely gets to zero.

Re: There Are No Bugs, Just TODOs

#163

Post by renox »

skybrian wrote: post #160
renox wrote: post #159

But if there is only TODOs and not bugs, how managers will prevent the creation of 'high severity bugs' when they're in panic mode? I wish I was joking but that's something to think about..

They create them and they go first in the queue. If there is more than one, they have to decide which is first. If there are conflicts then it's up to the managers to fight it out.

That's not what I'm talking about: when a software is late there is a 'panic phase' by the managers where they forbid the creation of 'high severity' bug tickets. So if there is no more bug tickets what will happen when the managers are in 'panic mode'? Something to think about before removing bug tickets.

Re: There Are No Bugs, Just TODOs

#165

Post by Almad »

jpswade wrote: post #129

Much of this is only from the perspective of the consumer, a developer. What businesses want is a way to be able to track progress and communicate priority. The difficulty for the the business is how they communicate their priority to you, that's what the priority field is for, it's a way for the person raising the issue to supply a way to communicate how important an issue is to you. The position in the queue is how…

Hmm, I communicated wrongly then. Because the separate system for issues is for a different team and a different purpose and no, it's definitely not a solution to the problem, but rather a prerequisite for the outlined system to have a chance at working at all.

Re: There Are No Bugs, Just TODOs

#166

Post by Almad »

cdcarter wrote: post #122

I'm going to add to the pile-on that the "Ticket Type" field is a little more useful than the author gives it credit. > why do you want to have this information and what is it going to be used for? You might say this is yet another proxy for priority, but it's slightly more nuanced than that. A lot of software companies do not have the experience of continuously deploying the main code branch. I work on a SaaS soluti…

Fair, although, depends on scale again. As they say, at scale, every implementation detail is something customers rely on :)

Re: There Are No Bugs, Just TODOs

#168

Post by Almad »

david_draco wrote: post #75

> One way to recover is to automatically close tickets after a certain period of time. This may be a subtle way of saying “no”, but I think it has its place, especially if we are talking about public trackers. Ugh, RedHat bugzilla trauma is coming back to me. Report issue -> 12 months nothing -> bug closed because new RedHat linux version was released. Repeat.

I do agree it can totally suck to be on the receiving side.

Re: There Are No Bugs, Just TODOs

#169

Post by skybrian »

renox wrote: post #163
skybrian wrote: post #160

Earlier quoted context omitted.

They create them and they go first in the queue. If there is more than one, they have to decide which is first. If there are conflicts then it's up to the managers to fight it out.

That's not what I'm talking about: when a software is late there is a 'panic phase' by the managers where they forbid the creation of 'high severity' bug tickets. So if there is no more bug tickets what will happen when the managers are in 'panic mode'? Something to think about before removing bug tickets.

Okay, hmm. It seems like if you already have a lot of high-priority work then logically, most new bugs will go after them in the queue.

And if you're running out of time, that would amount to the same thing, since you'll never get to it.

Also, so long as you have enough work queued up for a few weeks, there is not really much point to stack-ranking the remaining queue items anyway. Everything else is "lower priority".

Re: There Are No Bugs, Just TODOs

#170

Post by Almad »

hinkley wrote: post #92

> When people scream “this is a bug”, it is irrelevant what it is caused by. When people say things like this I often wonder if they worked with a more consistent caliber of people than I have. There are most definitely bugs, and figuring out that most of them come from a couple of people is critically important to saving the project in the long run. Knowing that you have 5 bugs and I have 7 is, I will agree, not imp…

I actually never new about bugs being assigned to people as opposed to products, interesting to know.
Post reply on HN