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

111–120 of 204 posts

Re: There Are No Bugs, Just TODOs

#111

Post by medius »

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…

To tackle this, I highly recommend the percentile technique from MIT paper, "A Structured Approach to Strategic Decisions". [1]

If you are judging any dimension, say priority, then assigning percentile rating to a task (i.e where does this given task stand relative to all the others) can be quite helpful to overcome the "SuperEvenMoreImportantEmergencyBugfix" cases. This is what the article is also suggesting.

And if you end up assigning 90% percentile to more than 50% of the tasks, you know your judgement is wrong, and it can be corrected accordingly. And it can also be standardized much better across the organization. Everyone can now judge their own judgements.

Rating on multiple dimensions with low correlations important for your company, say signup rate, retention, security, etc. and adding them up is a good way to not miss something important. It's not important to assign weights. Equal weights is fine [2]

I'm finding this technique quite useful in deciding what to work on next with fewer doubts about their priority. I failed to make Trello work for this and use a spreadsheet.

[1] A Structured Approach to Strategic Decisions - https://omegaleadership.com/media/Structured_Approach_to_Str...

[2] The robust beauty of improper linear models in decision making. - https://pdfs.semanticscholar.org/8793/408a67fd4c32bd7b5483d3...

Re: There Are No Bugs, Just TODOs

#112

Post by travisjungroth »

VBprogrammer wrote: post #34
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...

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…

That ticket comparison idea is awesome. You could have it for one person, or do it democratically.

I bet there'd be circular comparisons (A>B>C>A) a surprising amount of the time. Not a huge deal, you could just show the pairings back again in a different order until they resolve.

Re: There Are No Bugs, Just TODOs

#113

Post by allannienhuis »

bpyne wrote: post #37
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.

The user doesn't care whether the bug is in the requirements or if it's in the code. They just know that it's not working for them, and want it changed.

Arguing that it's not a bug seems like saying 'not my problem' to everyone else. I expect different companies have different cultures around assigning blame that might make saying 'not my fault' important, but I'm pretty sure that customers/users don't care one bit about that.

Re: There Are No Bugs, Just TODOs

#114

Post by foobiekr »

This is close to how I worked for years (mine: build a dependency graph and then order by dependency, work through a graph at a time). It caused a ton of friction with my work environment which was managers prioritizing bugs and then expecting you to work on them in priority order which, often, was nonsensical.

Re: There Are No Bugs, Just TODOs

#115

Post by taftster »

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 don't know that I've ever seen a feature that wasn't some sort of "failed promise". The feature sometimes hits and sometimes misses, and is usually somewhere in between. This idea that a defect is a failure of a feature is probably more to do with the inability to predict the future. Sure there are defects like you tried to read from /dev/null, but more realistically the "defects" you see today are more about the inability to predict exactly how a feature is going to be used.

Re: There Are No Bugs, Just TODOs

#116

Post by lazyant »

I enjoyed and mostly agree with these ideas. Some points though:

Re: Position In a Queue

> Every team must have a single ordered queue of tasks > every single one of them is prioritized relatively

This may lead in Eisenhower's matrix to prioritize urgent tasks vs important tasks and end up with tech debt.

I lead a soft eng team and we have a task queue but they are not prioritized (and that may be a mistake). Beyond the time wasting agonizing if X > Y for tasks, I like to keep parallel tracks of urgent (blocking) and tech debt tickets.

Re: Ticket Type

The most or one of the most important metric in software is user angry or happy calls (a proxy for revenue). If an unannounced planned feature doesn't make it to the next release, nothing happens. But if the customer now sees a regression bug (something that worked suddenly doesn't) that's bad. There's value in differentiating bugs from features, at least in some industries.

Re: Software Version

See Semantic Versioning https://semver.org/ ; it's important to know if a release is backwards-compatible or not

Re: There Are No Bugs, Just TODOs

#117

Post by taftster »

z3t4 wrote: post #76

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.

Um yeah. I mean, I appreciate your ideals. But back down here in the real world, part of that "project plan" is the part about taking a bite off the elephant. You've got to start somewhere. Defining and tracking the progress you've made eating the elephant allows you to know when you've fully consumed it.

And remember, most (all?) software projects are not defined in a singularity. They evolve. As users use the product, the understanding of what you built changes. There is no ability to define a project of any significant size in a box the first time. We aren't pulling rabbits from a hat.

Re: There Are No Bugs, Just TODOs

#118

Post by taftster »

kazinator wrote: post #83

The Software Version field should be used to identify the commit when the bug was introduced (perhaps the very first commit that introduced the entire thing in which the bug is found or perhaps a regressing commit). The way it's typically used is not helpful: namely that the user who reports the bug just fills in the version they happen to be running when it happened. There should be an Introduced-in Version and Fixe…

These fields aren't required for a good ticket system to work. They might be useful in terms of post-mortems, generating changelogs, etc. But fundamentally, the "version" that a issue was resolved in is not a requirement of the ticket tracking system. Some continuously deployed software doesn't really ever have a version number at all.

Re: There Are No Bugs, Just TODOs

#119

Post by lifeisstillgood »

>>> Every team must have a single ordered queue of tasks.

No. Every organisation. All the politics, all the empire building and compromises just to get along are brought into the fore and must be solved to decide if projectX is above or below projectY.

Do that, and we might just believe you are a company worth working for.

Re: There Are No Bugs, Just TODOs

#120

Post by taftster »

neonate wrote: post #103

There are no TODOs, just bugs.

You've made the same point as the author. The idea that a "ticket" or "work-item" has any sort of label (defect, feature, todo) or priority (high, low, now) doesn't add value. The label you give a work-item is meaningless. The value comes strictly from the change being applied.
Post reply on HN