This idea is very clever: “then ‘upkeep’ and ‘new’ should be the ticket types”
These can lead to discussions similar to "it's a feature, not a bug."
Is "Make app work on device X" or "Add cornercase Y" new or upkeep?
There Are No Bugs, Just TODOs
101–110 of 204 posts
Re: There Are No Bugs, Just TODOs
#102I 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…
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...
This works well in theory, until managers urge you to treat every task as "P-0" and you suddenly need to prioritize within the P-0's (we would jokingly use negative numbers instead).
Re: There Are No Bugs, Just TODOs
#103There are no TODOs, just bugs.
Re: There Are No Bugs, Just TODOs
#104The central point that work trackers track work is true important and jira astronauts need to be stopped, but the piece misses the bureaucratic purpose of jira: work legibility. Work tracking isn't just about figuring out what work needs to get done, it's about helping management get a picture for the state of work. Developers and other line workers don't care about obsolete vs won't do. But management does. They wan…
> There's a terrible principal agent problem here where management, the principal, decides how to track work, and can put the heavy lifting of filling in values onto the developers. This happens when management's more worried about losing their job than improving their team's output.
I no longer believe a single tool is good for both a team tracking & communicating amongst themselves about the work they're doing, and communicating the same to and among management. Trying to make them both the same thing is a great way to come up with something that's terrible for one or the other of those uses (usually the former).
Re: There Are No Bugs, Just TODOs
#105Interesting 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…
But you have to acknowledge some features are bugs.
For example, if you have a word processor, having a running word count sounds like a feature.
To a developer it seems frivolous, like having a LOC counter.
But to people who write professionally word count might be the most critical metric of all (like a progress bar for "article is done")
just saying... failed promises
Re: There Are No Bugs, Just TODOs
#106Github 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...
You only need something more complex or heavy than GH issues (if even that complex) if you've got someone bugging you for burndown charts and metrics and shit just all the time, or someone in the chain who just loves poking around and dragging shit from here to there ("oh goody I'm going to drag this into 'on ice', best day ever!"). The dragging action I don't bring up accidentally—it's very important, for some reason.
Re: There Are No Bugs, Just TODOs
#107> The toolset that completes the version control log to form the development equivalent of double-entry bookkeeping.
This made me wish for a "git commit --future" that lets you just track future things to work on within git itself. "git stash" is kinda connected into this concept as well, branches too if used as development caches. It gets a bit wonky with multiple repos, as well as non-code related tasks, but then we have a single location for tickets, and a UI could be created to connect with other teams.
Re: There Are No Bugs, Just TODOs
#108I 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] and I've found that to be true when working for people so good at using the software that they made popular training videos for it, not just morons who don't know how they work.
Re: There Are No Bugs, Just TODOs
#109It sounds to me like you're describing Pivotal Tracker ( https://www.pivotaltracker.com/ ). It forces story ordering (rather than "prioritization"), it's pretty barebones, and it's fast.
Both Jira and Trello allow ordering, how does this differ?
Re: There Are No Bugs, Just TODOs
#110> When people scream “this is a bug”, it is irrelevant what it is caused by. It is a scream of a significant expectation mismatch. The team should work on resolving it, regardless of whether it was caused by a developer diverging from the designed intent or because of the original intent going wrong.
As a user, it's extremely relevant to me. I paid for your product/service because of what it claimed to do. Bugs are ways in which it doesn't do that. (It doesn't matter to me if some other hypothetical features don't exist yet, because I was happy to pay for the product/service knowing it didn't have those features.) As far as I'm concerned, a bug is your company not holding up your end of the bargain, even though I've held up my end by paying for it. That's not a good look.
Another way to look at it is that a bug is downtime for a feature. Elsewhere, you say (system) downtime should be #1, "top priority of everyone" until it's fixed. But what good is the system being 'up' if it's still broken in the way that I need? When I lose power at home, it's no consolation to hear "The power grid as a whole is still up -- it's just your neighborhood that's not working", nor would I consider this reasonable justification for de-prioritizing fixing it.
Maybe your company is at the stage where attracting new users with features is more important than keeping existing customers with quality. But they say it's always easier to keep customers than it is to acquire new ones, and I've blackballed several companies because they no longer place the priority on quality that they once did. You should be aware of what you're giving up by de-prioritizing 'bugs', or pretending they don't exist. I see comments here on HN every day complaining about specific companies whose software quality suffers. It takes years to dig yourself out of that hole.