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

71–80 of 204 posts

Re: There Are No Bugs, Just TODOs

#71

Post by nicbou »

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.

They are sorted according to the project roadmap, usually by a person who understands business requirements, and a person who understands reality.

In my experience, it's usually done in a weekly meeting that involves a small subset of the team. We don't need to estimate tasks. We only need to know their logical order (dependencies) and priority (requirements). We don't need the whole team present for that.

If the requirements or reality change during the week, there is no cost to reordering the todo column. It doesn't change how much gets done, just in which order it gets done.

Re: There Are No Bugs, Just TODOs

#73

Post by stickfigure »

This describes Pivotal Tracker almost exactly. You can go into it cold turkey, but to get the best use out of it, it helps to be familiar with the Pivotal software development process.

The important thing to realize is that pivotal tracker is not a "bug tracker" in the traditional sense - a giant database where issues go to be forgotten until someone clears them out in batch three years later. In the Pivotal process there is a product manager whose primary responsibility is curating the backlog. There are no priorities, just position in the backlog. The PM should know what's in there, that's their job - they don't write code.

Engineers just grab stories off the top of the backlog.

Re: There Are No Bugs, Just TODOs

#74

Post by seph-reed »

Something this article completely overlooks is coder mental health. Working on bugs constantly is the equivalent of being a code janitor. Getting to own/run a new feature from time to time can re-invigorate your interest.

The suggestion I put out at an old company (which was shot down) was the idea of owning features. If all the bugs for features you own are resolved, pull a new feature. You now own the bugs for it.

It gets difficult when a feature is too big for one person, or too important for that developers bugs to be a blocker.

Re: There Are No Bugs, Just TODOs

#75

Post by david_draco »

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

Re: There Are No Bugs, Just TODOs

#76

Post by z3t4 »

Dont use todos or tickets or issue trackers! It takes too little effort to write a todo/ticket item. Your engineers will spend time doing work that are unnecesary and they will spend hundreds of hours implementing shitty ideas that only took 10s to come up with. Instead write down a project plan, write down the vision of the product. Write down what your goals are, and what you stand for.

Re: There Are No Bugs, Just TODOs

#78

Post by yiyus »

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 also means people will try to disguise feature requests as bugs in order to get a priority.

If my car breaks and cannot start, that's a bug. If I want to add a radio to my car, that is an extra feature. The difference exists, and it is important. You are saying this difference should be ignored because someone may try to pass the desire for a radio as a broken car. At that point, you could just ignore any issue because it may be a lie.

And the reason to categorize is not only to prioritize. For example, we have these rules: bugs require of a test case, and the test must pass to consider close the bug. On the other hand, new features are implemented first in a different tree, and the new feature needs to be documented (also in the tutorial). Moreover, we may have meetings to decide if we add a feature or not (for example, different new features may not work well together or may require extensive refactoring that we do not want to do), while a bug must be fixed.

In your workflow, this distinction may not be important. That's perfectly possible. But, in my opinion, claiming that "we collectively shouldn't care" is going to far (unless "we collectively" means something more specific than it looks to me).

Re: There Are No Bugs, Just TODOs

#80

Post by nicbou »

Almad wrote: post #56
junon wrote: post #46

Earlier quoted context omitted.

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.

That would be me. My job is to clarify requirements, gather assets and prepare tasks so that tickets spend less time in progress.

This involves adding a triage column before the todo column. This column is for tickets that are necessary, but not prioritised or ready to work on.

Post reply on HN