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

21–30 of 204 posts

Re: There Are No Bugs, Just TODOs

#21

Post by Almad »

code-faster wrote: post #14

The central point that work trackers track work is true important and jira astronauts need to be stopped, but the piece misses the bureaucratic purpose of jira: work legibility. Work tracking isn't just about figuring out what work needs to get done, it's about helping management get a picture for the state of work. Developers and other line workers don't care about obsolete vs won't do. But management does. They wan…

I do completely agree. In fact, when people asked me for JIRA, I've always said I am happy to do it since it's a software designed for me, the CTO.

Yet I refuse to do it to them, the ICs.

Re: There Are No Bugs, Just TODOs

#22

Post by nix23 »

TheRealPomax wrote: post #15
Etheryte wrote: post #13

Earlier quoted context omitted.

I think an important consideration is important for whom. If the only reason something is important is because of an arbitrary management deadline, the right response is to stand your ground and calmly finish working on what you already picked up. While I understand it's easier said than done, if you don't stand your ground, it won't get better. The polar opposite of this is when I personally broke something and it's…

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied.…

First i do what my boss says, when i did that and we both have a little time to talk, i explain to him why i was thinking the other stuff was more important, often he has a good point from a complete different perspective than i have, sometimes i 'win' from my 'technical' perspective, after some time passes you learn to read each other and decision's are made without questions, for me its super important to know each others and the base where decision's are made.

Re: There Are No Bugs, Just TODOs

#23

Post by emmelaich »

berkes wrote: post #5
dboreham wrote: post #3

For me none of the SaaS bug tracking systems are usable. They're all much worse than c. 1996 Bugzilla.

The only system that I appreciate is taiga. It's extremely opinionated and quite un-configurable. What I like about it, is that it enforces workflows (either scrum, kanban or simply one-large-backlog) The Way They Were meant. So it solves a lot of bikeshedding and solves me & my team from trying to invent "something that works for us". The idea proposed by OP works quite well there too, with kanban. Just pick the car…

A quick web search gives me taiga.io, taiga.pm.

What's the diff if any?

Re: There Are No Bugs, Just TODOs

#24

Post by eska »

TheRealPomax wrote: post #15
Etheryte wrote: post #13

Earlier quoted context omitted.

I think an important consideration is important for whom. If the only reason something is important is because of an arbitrary management deadline, the right response is to stand your ground and calmly finish working on what you already picked up. While I understand it's easier said than done, if you don't stand your ground, it won't get better. The polar opposite of this is when I personally broke something and it's…

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied.…

Yeah, the best you can do at that point is to meticulously document your work. You don't want to look unproductive and get fired just because you're constantly stopped from releasing your work. And in the case that you do get fired, you will want to give your lawyer some ammunition in the form of work logs outside of the ticket system, which you will be barred from.

Re: There Are No Bugs, Just TODOs

#26

Post by ahungry »

Interesting read - to a person working tickets, I think it can be true that there is no useful difference between viewing a task as a bug vs a feature - in either case, its "what needs to change" and performing work to do the change.

However, the big difference to people not handling the ticket (the customer/business + the person(s) who have to deal with bug accountability) - a bug usually represents a failed promise and is quite different from a feature.

If I go to a restaurant and there is a "bug" in my order, I expect it fixed for free, so that in the end I'm getting my original order (with the extra work/time requirement eaten by the side which erred to begin).

If I want to change my order because I don't like the food after all, then that's not a bug, that's a change in requirement/feature request.

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.

Re: There Are No Bugs, Just TODOs

#27

Post by emmelaich »

Almad wrote: post #16
mytailorisrich wrote: post #11

In general tickets describe change requests, and they are sometimes referred to as such (CRs): Someone wants the software/system to change in some way. A ticket type makes sense because bugs and new features are not the same and we should care about the difference. A bug is a defect in the implementation of a feature that should be fixed. A good practice is to fix defects before adding new features, as far as possibl…

This analytical approach is exactly what I disagree with. > A good practice is to fix defects before adding new features, as far as possible This is the approach I describe as "bug is a proxy for priority", where you are essentially saying it's "highest". It is a good approach in theory, but just ignores business realities. It also means people will try to disguise feature requests as bugs in order to get a priority.…

It is a fantastic article Almad, thanks!

About the only thing I might add is dependencies. But even that is mostly value for management reporting and time estimation. It doesn't help the workers do their jobs that much.

Re: There Are No Bugs, Just TODOs

#29

Post by bberenberg »

ahungry wrote: post #26

Interesting read - to a person working tickets, I think it can be true that there is no useful difference between viewing a task as a bug vs a feature - in either case, its "what needs to change" and performing work to do the change. However, the big difference to people not handling the ticket (the customer/business + the person(s) who have to deal with bug accountability) - a bug usually represents a failed promise…

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

Re: There Are No Bugs, Just TODOs

#30

Post by WrtCdEvrydy »

TheRealPomax wrote: post #15
Etheryte wrote: post #13

Earlier quoted context omitted.

I think an important consideration is important for whom. If the only reason something is important is because of an arbitrary management deadline, the right response is to stand your ground and calmly finish working on what you already picked up. While I understand it's easier said than done, if you don't stand your ground, it won't get better. The polar opposite of this is when I personally broke something and it's…

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied.…

I will usually drop a small comment saying 'deprioritized due to OTHER_TICKET_NAME' and mark the ticket as Done.
Post reply on HN