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

31–40 of 204 posts

Re: There Are No Bugs, Just TODOs

#31

Post by dataduck »

ehnto wrote: post #20
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...

I've seen good success with having an entirely different pipeline for rushed/rapid/panic tickets. The rapid pipeline reduces some of the ticket and procedural bureaucracy of the normal pipeline, and only lasts a sprint. That obviously comes with risk, so putting something in the rapid pipeline needs to be weighed properly. The somewhat untold benefit of this system, is it makes the product manager or client decide be…

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

Re: There Are No Bugs, Just TODOs

#33

Post by agloeregrets »

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…

For a pretty crazy take on this, take. A look at BaseCamp’s “Shape Up” philosophy, They do not have a backlog. Period. To them, they work a little slower and expect to give enough time to a task to ensure zero bugs instead but then have cycles of bug-fix focus. Additionally, something I found interesting is that every dev is expected to understand the complete stack, that way any dev can fix any corner. Sure this might not work in a larger company without strong levels of splitting up the product, but It’s an enjoyable thing to look at.

Re: There Are No Bugs, Just TODOs

#34

Post by VBprogrammer »

thombat wrote: post #6
berkes wrote: post #4

I appreciate how clearly it is written down. It is how I would like to work and have tried at numerous jobs. I do find that reality is hard, though. There's always that moment when you don't feel like picking "the one at the top". Maybe because you have time for "a quicky" maybe because after spending a week on Foo, you now want some Bar? What this also does not solve is the "panic shifting". When a business goes int…

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 at the top which we thought were priorities at some point and a whole bunch of crap in the middle which is unordered.

I keep thinking about some kind of system where people would rate the priority of one ticket against each other rather than against an arbitrary scale.

Re: There Are No Bugs, Just TODOs

#37

Post by bpyne »

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…

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.

Re: There Are No Bugs, Just TODOs

#39

Post by twic »

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…

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 receivable clerks notices that due dates aren't properly adjusted for public holidays. As a developer, do you know how big a deal that is? Probably not. Doesn't sound like a big deal. But maybe it means we're imposing penalty charges on customers where we shouldn't be, and that's a huge legal and reputational risk. Or maybe it really isn't a big deal! The boss will need to have a conversation with the clerk to learn all this, but maybe having a severity field is an ice-breaker for that conversation.

Re: There Are No Bugs, Just TODOs

#40

Post by nicbou »

This sums up why I like Kanban.

The TODO column is an ordered list of things to do. The job of the developer is to pick tasks from the top and move them towards the right. The task of management is to keep the TODO column sorted, and prevent tickets from being stuck in any other column.

The task of management is aided by limits on how many items each column contains. Those limits are based on how many things people can realistically do at once.

Post reply on HN