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

181–190 of 204 posts

Re: There Are No Bugs, Just TODOs

#181

Post by sheriff »

It's odd to me that the proposed Minimal Skeleton for tracking a bug doesn't include:

* who reported the issue * what they reported happening * what they expected to happen instead

For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue.

But it's worthwhile to have a place to track bug reports that can't yet be acted on by writing code. Sometimes it's not immediately clear what is happening or what should be done about it. Sometimes you need to reach out to the reporter(s) for more information or to let them know progress has been made.

Even with well-understood bugs, there can be a many-to-many relationship between the bug and the development work to be done. Sometimes you have many people reporting the same issue in different ways, and it's not initially clear that there's a shared root cause. Sometimes one bug report is best addressed in multiple phases of development work.

I'd argue that there's always someone who's managing all of the above, even if they're not using separate bug tracking software to formally do so. But as a team grows, making the investment to "show your work" a little more can make it a lot easier to collaborate and delegate.

Re: There Are No Bugs, Just TODOs

#182

Post by Agentlien »

sheriff wrote: post #181

It's odd to me that the proposed Minimal Skeleton for tracking a bug doesn't include: * who reported the issue * what they reported happening * what they expected to happen instead For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue.…

Another reason to include those fields is that reported bugs are often a case of misaligned expectations between those designing, implementing and testing a feature.

If you're forced to describe what happened and what you expected to happen it makes it very clear when those expectations do not align with those of the people designing or implementing it.

Re: There Are No Bugs, Just TODOs

#183

Post by jpswade »

Almad wrote: post #165
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.

You described it as a “separate system for handling questions for the development team”.

How do you propose that queue is prioritised and consumed by the development team?

Re: There Are No Bugs, Just TODOs

#184

Post by kissgyorgy »

We used the Ticket Type field with a totally different workflow. There was always one developer on each sprint whose task was to only bug fixes, nothing else. That person got the "Bug" Type tickets. It was always a mistake in existing implementation.

Re: There Are No Bugs, Just TODOs

#185

Post by Almad »

fredfjohnsen wrote: post #94
bberenberg wrote: post #29

Earlier quoted context omitted.

> 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 underst…

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…

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.

Re: There Are No Bugs, Just TODOs

#186

Post by Almad »

sheriff wrote: post #181

It's odd to me that the proposed Minimal Skeleton for tracking a bug doesn't include: * who reported the issue * what they reported happening * what they expected to happen instead For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue.…

Thanks, this made me think. My first knee-jerk reaction was something about things and implicitness, but after some consideration:

* I am not sure "who reported the issue" is actually important, but rather "who is the contact person to get more information about this issue" and "who should be informed when this is done for verification", where "verification" means "satisfies expectations now" (as opposed to QA meaning of the word)

* Reported happening/expectation is a good point for any expectation mismatch report. I am not sure it should be there for all issues though as I find it can decrease clarity in the same way artificially requiring the "As X, I need to do Y in order to achieve Z" does

Re: There Are No Bugs, Just TODOs

#187

Post by Almad »

kazinator wrote: post #88
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…

As mentioned, this is true for versioned software, not for continuously deployed SaaS.

Re: There Are No Bugs, Just TODOs

#188

Post by Almad »

uxamanda wrote: post #86

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…

True. I think one of the issues is slapping an issue tracking system on a bunch of different problems.

Re: There Are No Bugs, Just TODOs

#189

Post by Almad »

jpswade wrote: post #183
Almad wrote: post #165

Earlier quoted context omitted.

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.

You described it as a “separate system for handling questions for the development team”. How do you propose that queue is prioritised and consumed by the development team?

In both companies I've been using that, it was a very simple RT/JIRA-SD-style system: "open a subject/text ticket, clock starts ticking, on call engineer gets a non-wake-up memo and will reply with high priority during work hours" and ticket will get closed ASAP and we do achieve inbox 0 regularly.

Yes, there are obvious issues and it requires two things to work:

1) If you actually have no clue about the product, you are respectfully told to fuck off to normal user support channel 2) If you keep misusing this for user support / slack channel, you get your access revoked.

...which are hard sells in large companies, of course—on the other hand, in BigCo I got success in getting an engineering headcount to accommodate that.

Re: There Are No Bugs, Just TODOs

#190

Post by Almad »

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..

If you mean how to prevent them, well, no bugs so no way to create them.

If you mean how they handle them, there is an incident procedure for that. If it's not really an incident but, well, I need this next week for Gartner Magic Quadrant...I have phone numbers of managers in my reporting chain.

Post reply on HN