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

61–70 of 204 posts

Re: There Are No Bugs, Just TODOs

#61

Post by nicbou »

zakallen wrote: post #59

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

It's my full time job, and I agree. However keeping Jira in line with reality helps me catch inconsistencies in requirements and plans.

Re: There Are No Bugs, Just TODOs

#62

Post by mytailorisrich »

Almad wrote: post #53
mytailorisrich wrote: post #41

Earlier quoted context omitted.

This analytical approach is the reality of managing tickets taking technical and business realities into account. A bug is not a proxy for priority. As said it is a parameter that helps defining a priority and, in fine, the position in the TODO list. Whether priority is "high", or P1, or whatever is exactly the same. Usually there no need for too many levels because, as you suggest, it mostly boils down to "now", "af…

I'd agree with you if I would be only seeing the teams through my management reports and not from the trenches. I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".…

> I am envious of the environment where you never saw somebody trying to bug feature request as a bug.

Really, I have never seen that in 20 years.

Of course that is different from another team or the test team raising a bug because they expected something that was not in the spec. Then you tell them that it's not because it does not behave the way they want that it is a bug. But, yes, a defect (more general term than bug) is any deviation from requirements.

Direct input from customers is different as well. Unless there is a contractual impact, if a customer is adamant something is a bug when it technically isn't then there is no point arguing. You can treat the request however you want internally.

Re: There Are No Bugs, Just TODOs

#63

Post by wpietri »

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 rushing to score points, or to cover up for earlier neglect.

If everything is urgent, nothing is urgent. Even in an early-state startup, where urgency abounds, it's possible to work with a measured pace and clear focus. I've done it! https://williampietri.com/writing/2015/the-big-board/

The fact that larger, more stable companies fail to create order is not because it's impossible. It's because the people with power either don't care or have interests that actually work against getting things done quickly and reliably.

Re: There Are No Bugs, Just TODOs

#64

Post by twic »

crdrost wrote: post #42
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…

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; these are just a roundabout way of him expressing his thoughts, but because they're structured as a debate, i think he gives himself a bit of unearned authority when he runs rings around his imaginary opponent:

https://twitter.com/swardley/status/1082647878349324288

Re: There Are No Bugs, Just TODOs

#65

Post by adrianmsmith »

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…

> They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.

I've heard the ability to drag & drop tasks around in an ordered list (i.e. a task only has priority relative to others, i.e. it's position in the list) as "ordinal priority".

Re: There Are No Bugs, Just TODOs

#66

Post by wpietri »

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…

> There's always that moment when you don't feel like picking "the one at the top".

A few solutions for this that have worked for me:

* Small units of work

* Having a tech-debt backlog broken into short lumps of cleanup, so you can "take a break" with something different

* Pair programming with frequent pair rotation. The next ticket is always taken by the next open pair, but you can work one something different every few hours if you need.

* trade tasks with a colleague

* sighing, saying, "well, this is my job," and picking the top thing anyhow

Re: There Are No Bugs, Just TODOs

#68

Post by chias »

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…

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

Re: There Are No Bugs, Just TODOs

#69

Post by adrianmsmith »

> there should be an algorithm that everybody should agree on. An example may be:

> - If there is downtime, it’s the top priority of everyone affected

> - If there is an incident, it’s the top priority for an on-call agent

> ...

Very much agree about this.

The trouble with "high priority" and "low priority" etc. is that different people perceive different things as having different urgency and importance. As long as you have >1 person entering tasks, each using their own algorithm to assign priority, a "sort by priority" (the only point in having a "priority" field at all as far as I can see) becomes completely useless.

If you use names like "downtime" or "incident" then, as the author writes, everyone can agree. That's the important thing I think. Then a "sort by priority" can yield something meaningful.

Plus there's the fact that when you have pages of "highest priority" tickets, managers just create all new tickets at that level, "otherwise they won't get seen and done" (true story)

This way of working annoyed me so much I wrote a blog post about it: https://www.databasesandlife.com/priorities/

Re: There Are No Bugs, Just TODOs

#70

Post by hyperpape »

One missing thing: maximize the number of things that can safely avoid going through the bug tracker, because the tracker represents overhead and (even more importantly) latency.

Does that marketing website typo fix need to go through the development team and require a ticket? There are reasons it might, but fixes will never really be fast enough if it does.

Or worse, what if a developer has to ask someone to create a task and add it to the board to add documentation to a method? Then either no will ever document anything, or they'll sneak those changes into other tasks, slowing down code review and feature development.

One way you can create those pathologies is to have auditors, and promise the that "all code changes follow a process" and soon you're signing forms in triplicate to make any kind of change whatsoever.

Post reply on HN