There Are No Bugs, Just TODOs
almad.blog
There Are No Bugs, Just TODOs
1–10 of 204 posts
Re: There Are No Bugs, Just TODOs
#2This idea is very clever:
“then ‘upkeep’ and ‘new’ should be the ticket types”
Re: There Are No Bugs, Just TODOs
#3For me none of the SaaS bug tracking systems are usable. They're all much worse than c. 1996 Bugzilla.
Re: There Are No Bugs, Just TODOs
#4I 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 into panic mode (deadlines, rough patch, downtime, chaos) you'll often see that tickets get moved from underneath you while working at them.
- Holdit, I'm done 80% with that SuperImportantEmergencyBugfix. Can I not finish and deploy it? - No, there now is a SuperEvenMoreImportantEmergencyBugfix that has to be fixed two hours ago.
No ticket system will fix that, but anything that helps with those moments is very helpfull, I guess.
Re: There Are No Bugs, Just TODOs
#5For me none of the SaaS bug tracking systems are usable. They're all much worse than c. 1996 Bugzilla.
The only system that I appreciate is taiga. It's extremely opinionated and quite un-configurable.
What I like about it, is that it enforces workflows (either scrum, kanban or simply one-large-backlog) The Way They Were meant. So it solves a lot of bikeshedding and solves me & my team from trying to invent "something that works for us".
The idea proposed by OP works quite well there too, with kanban. Just pick the card at top, and never have more than one card per working person in "active" at any time.
Re: There Are No Bugs, Just TODOs
#6I 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...
Re: There Are No Bugs, Just TODOs
#7I 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…
In my experience, the relative queue _is_ helping with that since you can be explicit. If SEMIEB is really more important than SIEB, it's fair to switch—but it should be done as a relative comparison / override. I mostly saw people pushing SEMIEB without being aware what they are pushing down.
Although I would agree that if you have to reshift on hourly basis, this sounds more like oncall than normal dev work :)
Agreed on "on the top" not always being viable / feeling like it, but it helps when you go top-to-bottom consciously as opposed to randomly.
Re: There Are No Bugs, Just TODOs
#8I 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…
[deleted]
Re: There Are No Bugs, Just TODOs
#9For me none of the SaaS bug tracking systems are usable. They're all much worse than c. 1996 Bugzilla.
The only system that I appreciate is taiga. It's extremely opinionated and quite un-configurable. What I like about it, is that it enforces workflows (either scrum, kanban or simply one-large-backlog) The Way They Were meant. So it solves a lot of bikeshedding and solves me & my team from trying to invent "something that works for us". The idea proposed by OP works quite well there too, with kanban. Just pick the car…
Oh cool, didn't knew about it and it looks like it may be the sweet spot.
Re: There Are No Bugs, Just TODOs
#10This 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. The software doesn’t handle all the real world crap that comes up when people try to use it. It can’t make the jump out of the local maximum. So instead, we get people endlessly iterating on the same ideas and releasing the same basic project trackers with slight twists.
Also, I think there’s a billion dollar company for someone who can make an internal support tool that people will actually use.