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

141–150 of 204 posts

Re: There Are No Bugs, Just TODOs

#141

Post by randomdata »

aflag wrote: post #90
randomdata wrote: post #82

Earlier quoted context omitted.

For most projects, sorting leads to prioritizing, which is an anti-pattern. For those who choose to eschew proper software development practices, it is nice that Projects is its own thing.

I don't think that prioritizing in general is an anti-pattern. You will do things before other things and you need to choose what to do first. The criticism in the article was about bad prioritization. With GH Projects you can have the liberty to queue issues however you may see fit.

The anti-pattern is premeditating priority. It is true that you have to consider all angles and ultimately determine where to start, but once you've done that it makes no difference where an issue lies in a list.

Re: There Are No Bugs, Just TODOs

#142

Post by VBprogrammer »

jschwartzi wrote: post #99
VBprogrammer wrote: post #34

Earlier quoted context omitted.

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

Re: There Are No Bugs, Just TODOs

#143

Post by ahungry »

allannienhuis wrote: post #113
bpyne wrote: post #37

Earlier quoted context omitted.

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

Right, to the customer it doesn't matter (just like to the developer it doesn't need to matter either - it just means the work needs to be performed).

However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.).

Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.

Re: There Are No Bugs, Just TODOs

#144

Post by gregmac »

protonimitate wrote: post #43
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…

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…

Whoever is giving your team heat about bug metrics needs to read about Goodhart's Law.

There's so many ways to influence number of bugs that it's pointless to measure anything that way. For example, do you make a single bug that lists 15 typos spread around, or 15 bugs (because after all, each typo is a different word and in a different part of the app). Do you accept vague but obviously real bugs while you try to collect enough info over time, or immediately close them as "cannot reproduce"? Is that a bug, or really a feature request?

Re: There Are No Bugs, Just TODOs

#145

Post by lostinroutine »

arunc wrote: post #128

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

There is no CSS on the page. I have a feeling your comment was facetious though, hinting at the amount of bloat (e.g. Jekyll theme) we need today to do the simplest things.

Re: There Are No Bugs, Just TODOs

#146

Post by rconti »

hinkley wrote: post #92

> When people scream “this is a bug”, it is irrelevant what it is caused by. When people say things like this I often wonder if they worked with a more consistent caliber of people than I have. There are most definitely bugs, and figuring out that most of them come from a couple of people is critically important to saving the project in the long run. Knowing that you have 5 bugs and I have 7 is, I will agree, not imp…

Would people otherwise be aware that Steve has an order of magnitude more bugs than anyone else?

Re: There Are No Bugs, Just TODOs

#147

Post by hackbinary »

Almost certainly what you can fix and release in an hour has higher priority than something that is going to take a month, for example.

I have had quite a bit of success in having the technical teams assess the length of time a fix or a feature takes to do, but letting the stakeholders determine the relative priority.

I have seen requests and suggestions go from completely critical when requested, but when estimated at a couple of work then broken down into multiple much easier and clearer tasks when the stakeholders are included in the prioritisation discussion.

My experience is that stakeholders much prefer having things turned around quickly and they will what they can to optimise for things that are quickly and easily deliverable.

Re: There Are No Bugs, Just TODOs

#148

Post by lifeisstillgood »

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 love the restaurant analogy - it has great resonance especially if you consider cost of making it right.

If I order a Lasagne and get spaghetti meatballs, i think that's a big and i expect to be fixed.

If I order Lasagne and get Beef Lasagne when Inamna vegetarian then I still think it's a big, but the failure is not immediately in the kitchen - why did the waiter not check, if I am wearing dungarees and a a Tee Shirt saying "Die all meat eaters" should that be a clue?

And what about the kitchen response - we all like the restaurant that apologises and comps the food for free. But we would be a bit surprised if we were told the Beef Lasagane was not going to be refunded and we had to pay again to get the veggie one.

But all those models exist in software.

Re: There Are No Bugs, Just TODOs

#149

Post by gregmac »

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…

As a developer, I generally find having a distinction between bugs and features useful.

If I'm going to do a big refactoring of some component, I find it useful to look for related open bugs (even if they're low severity) because sometimes it's low or zero extra effort to fix them at the same time. This only works if you have good quality tickets though (proper tags, alias words, etc), which is a whole different topic.

I think it also reduces cognitive load while looking at tickets to have them categorized that way too. Of nothing else being visually distinct (via icon or something) just makes it easier to process.

Above all though, it's important not to argue about bug vs feature. Ideally any bug can link to the feature ticket that isn't working, but either way it's more important to make things better for the customer, so if that means considering a what is really a feature request a "bug" because it'll cause a big argument otherwise, then do that.

Re: There Are No Bugs, Just TODOs

#150

Post by lazyant »

twic wrote: post #64
crdrost wrote: post #42

Earlier quoted context omitted.

There's a great manufacturing-management book that regrettably speaks to a manufacturing context and not a project context and therefore applying it literally to our software projects would be a fallacy, called “The Goal”—and then the rederivation of the same principles for project management is in a follow-up book called “Critical Chain.” They are both weird in that they are textbooks written as novels and therefore…

The Phoenix Project is a software instance of one of these textbooks-as-novels: https://itrevolution.com/book/the-phoenix-project/ https://itrevolution.com/wp-content/uploads/files/PhoenixPro... And Commitment is about software projects, and is a graphic novel (with a female protagonist!): https://hennyportman.wordpress.com/2016/05/29/review-commitm... I'm also reminded a bit of Simon Wardley's dialogues with X; thes…

The Phoenix Project has several main characters but arguably the main one is also a woman, as well as other characters (meaning not only one).
Post reply on HN