There Are No Bugs, Just TODOs • Hacker News Board

Re: There Are No Bugs, Just TODOs

#121

Post by Etheryte » Fri, Jun 05, 2020, 6:58 PM UTC

cerberusss wrote: post #100

Etheryte wrote: post #48

Earlier quoted context omitted.

I sincerely disagree. Taking the extreme case you described as either do it or be fired, the other party wants a result, a task done or something similar, which still won't be done if they would fire you on the spot. It seems you misread my reasoning as blindly standing your ground which is not the case I was making. If there is a good reason to switch what you're working on, you should, as I also said above. But if…

I remember when I had ~3 years of working experience. We were on the tail end of a fixed price/fixed date contract. There was a bug that needed to be fixed, and it was in a module that everybody had worked on, and the code was pretty bad. So during the meeting, I said: that bug is just a sympthom, the module needs to be rewritten. And I knew what I was talking about. No, said a senior, we're just going to fix the bug…

In that case there clearly is a good reason though? In the scenario described, you have one known bug, in the case of a rewrite you have an unknown number of bugs. Surely, both approaches may have more unnoticed bugs in them but in the former case people have already tested the solution so that's less likely. When you rewrite, you enter new untested territory with more room for new bugs.

Re: There Are No Bugs, Just TODOs

#122

Post by cdcarter » Fri, Jun 05, 2020, 6:58 PM UTC

I'm going to add to the pile-on that the "Ticket Type" field is a little more useful than the author gives it credit.

> why do you want to have this information and what is it going to be used for?

You might say this is yet another proxy for priority, but it's slightly more nuanced than that. A lot of software companies do not have the experience of continuously deploying the main code branch. I work on a SaaS solution that's gained traction in highly regulated industries.

It's very useful to be able to identify (trends in!) bugs that could be described as a "regression" or breakage in behaviors that customers are known to rely on. This isn't the example of "Customers" from your post though, ultimately how the change gets prioritized and released is what they care about! This is about being able to identify and systemically manage change in high risk areas.

Re: There Are No Bugs, Just TODOs

#123

Post by mumblemumble » Fri, Jun 05, 2020, 6:58 PM UTC

wpietri wrote: post #63

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…

The panic shifting thing is real, and for me way too many companies operate in permanent panic. I'm fine with responding to actual crises. But so much "urgent" work is really just managerial failure. Fake deadlines used to "motivate" people. Broken processes that people work around. Executives urgently need to look like they're doing something. Easily solvable problems festering until they become crises. Managers rus…

> people with power either don't care or have interests that actually work against getting things done quickly and reliably.

This is what I have seen, time and time again. Decision makers don't work for their employer, they work for their compensation package. It's amazing what one can rationalize when one thinks it might positively impact some number that's mechanically tied to one's bonus.

I've also seen it arise as a simple "too many cooks in the kitchen" situation. Ironically, the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time.

Re: There Are No Bugs, Just TODOs

#124

Post by taftster » Fri, Jun 05, 2020, 7:03 PM UTC

Great quote from TFA:

> Once you start assigning priorities from a list, anything else than “Highest” is a passive-aggressive way of saying “No”.

What can be gamed will be gamed. Once you start applying the equation "feature = good & defect = bad" or assigning arbitrary priorities "high, really high, now, yesterday", you are in effect providing opportunity to game the system.

Story points have this quality. More points are good, less points are bad. Let the games begin.

The value of a ticket / work-item comes strictly from the changes made to the underlying system. The "diff" effectively. The labels and types that we assign to work-items don't actually add any real value to the system.

Re: There Are No Bugs, Just TODOs

#125

Post by coelh0 » Fri, Jun 05, 2020, 7:14 PM UTC

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.

Don't confuse the waiter with the customer.

If the waiter gets the request wrong from the customer, it's still a bug. Even if the kitchen does exactly what was in the waiter request.

It's a team effort.

Re: There Are No Bugs, Just TODOs

#126

Post by taftster » Fri, Jun 05, 2020, 7:17 PM UTC

cdcarter wrote: post #122

I'm going to add to the pile-on that the "Ticket Type" field is a little more useful than the author gives it credit. > why do you want to have this information and what is it going to be used for? You might say this is yet another proxy for priority, but it's slightly more nuanced than that. A lot of software companies do not have the experience of continuously deploying the main code branch. I work on a SaaS soluti…

Most if not all software is shipped with known defects. So clearly, the fact that a "bug" can be identified doesn't give any weight when describing when it needs to be fixed.

A missing feature can be just as onerous to a user as a defect. Understanding if an issue gets in the way of productivity is all that matters, regardless if it's described as a bug or a feature.

Tracking metrics against bug vs. feature is a surefire way for a system to be gamed. If there are consequences in finding/reporting defects, then all work-items will eventually be labeled as "features". Or if you reward finding bugs, then all work-items will gravitate towards "defects". It's up to you how you want to play this game.

Re: There Are No Bugs, Just TODOs

#127

Post by taftster » Fri, Jun 05, 2020, 7:33 PM UTC

lazyant wrote: post #116

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…

A bug report does not imply a user is angry or not. Software is shipped with known bugs which often go unfixed. And a lack of features can be just as critical of an impediment for a user. So neither bug nor feature can fully describe the effect that an identified issue has on its overall priority.

An angry phone call doesn't universally change the order of work for all companies. Some projects might rate this event more importantly than other projects. Most angry phone calls are a result of usability problems not strictly feature defects. So there's no direct correlation here between user product sentiment and backlog priorities, unless your company culture adds that correlation.

Re: There Are No Bugs, Just TODOs

#128

Post by arunc » Fri, Jun 05, 2020, 7:34 PM UTC

The website theme is nostalgic. Does anyone know of jekyll theme that generates such simple website?

Re: There Are No Bugs, Just TODOs

#129

Post by jpswade » Fri, Jun 05, 2020, 7:42 PM UTC

Much of this is only from the perspective of the consumer, a developer.

What businesses want is a way to be able to track progress and communicate priority.

The difficulty for the the business is how they communicate their priority to you, that's what the priority field is for, it's a way for the person raising the issue to supply a way to communicate how important an issue is to you.

The position in the queue is how you (and presumably your team) should decide what order to tackle the work in.

The final point is the solution to the problem is to create another system for issues, which goes against the point that says "every team must have a single ordered queue of tasks".

I find it interesting that the solution to, in their own words, "One of my life’s traumas" is to add another issue tracking tool.

Are we trying to fix the right problem?

Re: There Are No Bugs, Just TODOs

#130

Post by jpswade » Fri, Jun 05, 2020, 7:47 PM UTC

travisjungroth wrote: post #10

This post solidifies an idea that’s been kicking around in my head: software tends to push productivity towards a local maximum. Let’s say the author is right and ticket queues should be a single stack with no priority. That seems pretty easy to make. Easy enough on a popular enough topic that I’m sure it’s been done. But, I’ve never seen or even heard of one in use. Why? Because it forces people to make hard choices…

Kanban is effectively this.

It works to an extent, but then someone somewhere usually has an abstracted concept of priority, otherwise you end up with priority as per the "highest paid person's opinion".