There Are No Bugs, Just TODOs • Hacker News Board

Re: There Are No Bugs, Just TODOs

#51

Post by nicbou » Fri, Jun 05, 2020, 4:14 PM UTC

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…

In my experience, it worked better with Kanban.

The "top ticket first" approach forced us to improve knowledge sharing in the team. In practice, you can pick the second topmost ticket if it doesn't affect the schedule. You're a grown up.

The tickets you work on should not be based on your feelings, but on actual priority. In practice, if you feel like it won't affect the schedule, go for it. You're a grown up.

In my experience, panic shifting is more manageable with Kanban. Tickets aren't given arbitrary deadlines, so shifting them around doesn't change the order of work, but not the intensity of work. Bringing one ticket up pushes every other ticket down. Nothing gets squeezed into the sprint.

As for interruptions, it's a matter of urgency. Usually, Kanban dictates what you do next, not right now. There's also a limit on how many tickets you can have in progress. In practice, it's up to you to decide if a task is urgent enough to interrupt your work. You're a grown up.

Re: There Are No Bugs, Just TODOs

#52

Post by gitgud » Fri, Jun 05, 2020, 4:17 PM UTC

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

Re: There Are No Bugs, Just TODOs

#53

Post by Almad » Fri, Jun 05, 2020, 4:17 PM UTC

mytailorisrich wrote: post #41

Almad wrote: post #16

Earlier quoted context omitted.

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

This analytical approach is the reality of managing tickets taking technical and business realities into account. A bug is not a proxy for priority. As said it is a parameter that helps defining a priority and, in fine, the position in the TODO list. Whether priority is "high", or P1, or whatever is exactly the same. Usually there no need for too many levels because, as you suggest, it mostly boils down to "now", "af…

I'd agree with you if I would be only seeing the teams through my management reports and not from the trenches.

I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".

Fair on distinction of severity by customer vs priority by team, although I am used to make a distinction between support ticket by customer and issue in engineering team's queue.

Lead implies either managerial or technological leadership and especially in mature organisations, I've seen both.

My experience with management by bug statistics is...very inconsistent as it motivates people to game the system...and boy I've seen that a lot. I do agree trend knowledge helps, but I am not sure it's worth the side-effects and work.

Of course, a flavor of this depends on context (and scale). It is very different if you have a single-instance SaaS, distributed system or images shipped to air-gapped systems.

Re: There Are No Bugs, Just TODOs

#54

Post by ydlr » Fri, Jun 05, 2020, 4:18 PM UTC

twic wrote: post #39

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

Re: There Are No Bugs, Just TODOs

#55

Post by Almad » Fri, Jun 05, 2020, 4:18 PM UTC

arnklint wrote: post #28

On point in so many ways... There is simply no way of decentralize prioritization. Thanks Almad, for sharing valuable insight/realization with the rest of us.

Happy to, glad you like it

Re: There Are No Bugs, Just TODOs

#56

Post by Almad » Fri, Jun 05, 2020, 4:20 PM UTC

junon wrote: post #46

nicbou wrote: post #40

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

I disagree. Who is sorting those tickets? Are they sorted arbitrarily or were the technicals considered? Is the ticket at the top feasible given the current state of the codebase/product? In theory this would work, but it has the pre-requisite that whomever is managing tickets understands technology - which, in my 10 years in the field, has been quite rare.

In my experience, the final sorting needs to be done by a collaboration between ticket manager and someone-who-understands-technology anyway. If the ticket manager doesn't have a clue, they can't make judgement calls necessary as for nontrivial software, it can be hard to say if this is one day or one year of work.

And that affects prioritization a lot.

Re: There Are No Bugs, Just TODOs

#57

Post by mytailorisrich » Fri, Jun 05, 2020, 4:21 PM UTC

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

This does not mean that having priority is not useful, this just means that they did it badly.

Everything is prioritisation. I'd say that prioritisation is one for the key skill of people leading organisations.

People who can't do it will fail whatever tools they use.

Re: There Are No Bugs, Just TODOs

#58

Post by Almad » Fri, Jun 05, 2020, 4:22 PM UTC

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.

Re: There Are No Bugs, Just TODOs

#59

Post by zakallen » Fri, Jun 05, 2020, 4:23 PM UTC

I feel the same way about Asana and Jira. They're so customizable and cater to too many people that it requires management to be someone's full time job. And I haven't found someone who is passionately in support of such as service as you might find with say Notion.

I've been working on a project that is attacking this problem but from the TODO comments angle. https://cosmolabs.io

Re: There Are No Bugs, Just TODOs

#60

Post by zelphirkalt » Fri, Jun 05, 2020, 4:28 PM UTC

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…

Time for a quicky is always good to have. When I don't however, I usually take that "annoying" task and see, whether I can divide into sub tasks. Divide and conquer often helps. If that does not work, I make a list of steps, which I need to take to accomplish whatever the task is about.