I don't agree. I think it is useful to have a list of "things we should seriously considering doing when we get the time even if they aren't an immediate priority".
Just because you have coding agents, doesn't mean suddenly every such idea should be done immediately. You can come up with a hundred ideas much faster than you can review the work of a hundred agents tasked with implementing them.
The backlog should just be bounded. At any fixed budget (for deveopers or tokens), there is a fixed capacity. That implies prioritization and it implies not doing things now but doing them later.
But unbounded backlog is dumb. Obviously some things will just never be done and it's better to be honest and drop them rather than just let the backlog grow forever.
The usual bottleneck is that you don't know which tickets in the backlog are higher or lower priority. You have to look and prioritize the backlog and... prioritizing tickets that aren't important enough to work on now is the definition of fluffy bs things to spend time on.
So in practice, the backlog gets "prioritized" by being ignored. If something is important, it'll come up again and reality will force you to do it, not the issue sitting unlooked at in linear
I think it's useful to have, even if just to have a calibration of what priority level is "never get done" (which will probably change over time) and a list of things that have been considered and fall below that level. Obviously rearranging the priority of stuff below that threshold is pointless but that's a seperate problem to having the list.
Seems further along the philosophy of closing bugs because they are old..
Completely bizarre then and IMO even more wrong now. If AI is supposedly catching up on architecture and design then it should be able to map the correct way to address the constraints and size of implementing lots of related and conflicting directions by making system, user, etc configurations to not hit a minima every week like an idiot who considers one request at a time and can't take back previous decisions once published.
The core concept of a backlog is that some half-assed idea will sit in storage for years... then somehow sprout into a viable software project. Without any research, effort, investment, or design intent.
This is empirically false, especially in the age of LLMs. Intent is everything.
I don't agree. I think it is useful to have a list of "things we should seriously considering doing when we get the time even if they aren't an immediate priority".
Just because you have coding agents, doesn't mean suddenly every such idea should be done immediately. You can come up with a hundred ideas much faster than you can review the work of a hundred agents tasked with implementing them.
I keep my TODO.md sorted by priority first, then by ease of fixing. Highest priority and easiest stuff to fix is at the top of the list.
I don’t always work on stuff in that order, however. And a single PR might fix multiple TODOs.
The backlog should just be bounded. At any fixed budget (for deveopers or tokens), there is a fixed capacity. That implies prioritization and it implies not doing things now but doing them later.
But unbounded backlog is dumb. Obviously some things will just never be done and it's better to be honest and drop them rather than just let the backlog grow forever.
The usual bottleneck is that you don't know which tickets in the backlog are higher or lower priority. You have to look and prioritize the backlog and... prioritizing tickets that aren't important enough to work on now is the definition of fluffy bs things to spend time on.
So in practice, the backlog gets "prioritized" by being ignored. If something is important, it'll come up again and reality will force you to do it, not the issue sitting unlooked at in linear
I think it's useful to have, even if just to have a calibration of what priority level is "never get done" (which will probably change over time) and a list of things that have been considered and fall below that level. Obviously rearranging the priority of stuff below that threshold is pointless but that's a seperate problem to having the list.
Seems further along the philosophy of closing bugs because they are old.. Completely bizarre then and IMO even more wrong now. If AI is supposedly catching up on architecture and design then it should be able to map the correct way to address the constraints and size of implementing lots of related and conflicting directions by making system, user, etc configurations to not hit a minima every week like an idiot who considers one request at a time and can't take back previous decisions once published.
Love it. The backlog was dead long before LLMs.
The core concept of a backlog is that some half-assed idea will sit in storage for years... then somehow sprout into a viable software project. Without any research, effort, investment, or design intent.
This is empirically false, especially in the age of LLMs. Intent is everything.