Live data from Hacker News

There Are No Bugs, Just TODOs

almad.blog

151–160 of 204 posts

Re: There Are No Bugs, Just TODOs

#151

Earlier quoted context omitted.

That’s the whole point of that backlog. The order should reflect the priority of everything relative to everything else. You drag stuff up above other stuff that is lower priority and part of everyone’s job is to groom that list so it reflects reality.

While that may be true in theory in practice it is difficult. A big improvement would be if new things needed to be inserted into the backlog at an appropriate place but I don't know if it's possible to do that in Jira.

This, I think, is exactly why everyone I know who is happy with their backlog management does it in an Excel spreadsheet or Google Sheets.

I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.

Re: There Are No Bugs, Just TODOs

#152

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

Working in Jira and (especially) Asana always feels like working on a VNC share of the person in charge's cluttered desktop-covered-in-folders organizational system. Everything's hard to find and I'm afraid to touch anything for fear I'll accidentally drag something somewhere then not be able to find it again to put it back. Except it's that plus 1.5GB of memory use and a few tens of a % of a processor core. [EDIT] a…

Sometime I wish that my project was managed in a folder with neatly arranged subfolders all in ASCII text. Specs in the specs-folder. Release lists in the release list folder.

Bugs in the bugs folder, with a text file for "reported", "active" and "fixed" bugs sorted by release version folders.

I honestly would want to try it. Files and folders are the abstraction that was supposed to replace physical folders with files, but in practice files stored in computers/network/mail are just a bunch of papers randomly put everywhere. How about using folders as they were supposed to ...

Re: There Are No Bugs, Just TODOs

#153

Earlier quoted context omitted.

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied.…

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…

Every junior and intermediate dev would like a word with that concept, because it sounds magical. Once you have a few years at an org under your belt, you have the creds to pipe up, but until then, you either talk with the better devs in private and hopefully convince them, or you do what your boss told you to do.

Re: There Are No Bugs, Just TODOs

#154

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

thanks for this nuances.

Re: There Are No Bugs, Just TODOs

#157
post #58
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.

We use priority tagging, which allows you to group collections of bugs say: "urgent" . But yes it's hard to actually order the priorities... Haven't tried github projects yet

Re: There Are No Bugs, Just TODOs

#158
post #68

Earlier quoted context omitted.

Yup - from a implementation perspective, bug vs feature is a artificial designation. Where I think it _does_ matter, is when a business wants to track metrics like "# of bugs over time" or "# of bugs per feature". My team recently got a lot of heat about "a rising number of bugs", and the insinuation was that our code quality was poor. Turns out, > 75% of the "bugs" reported were mis-labeled feature requests or lack…

One way the distinction gets used where I work is to have custom / required fields keyed on the ticket type. Oh, you want to make a bug ticket in my project? In that case, required fields include "steps to reproduce", "expected result", and "actual result". You want to make a feature ticket in my project? In that case, required fields include "rationale" and "acceptance criteria".

Earlier this year, I reported a bug in Firefox. In my report, I included steps to reproduce the issue, the expected result and the actual result (because I've been on the other side). There were no back-and-forth messages to clarify the issue, and it was fixed in a short amount of time (well, short for a project of that size).

Re: There Are No Bugs, Just TODOs

#159
But if there is only TODOs and not bugs, how managers will prevent the creation of 'high severity bugs' when they're in panic mode? I wish I was joking but that's something to think about..

Re: There Are No Bugs, Just TODOs

#160
post #159

But if there is only TODOs and not bugs, how managers will prevent the creation of 'high severity bugs' when they're in panic mode? I wish I was joking but that's something to think about..

They create them and they go first in the queue. If there is more than one, they have to decide which is first.

If there are conflicts then it's up to the managers to fight it out.

Post reply on HN