| ▲ | Do or do not. There is no backlog(ben.page) | |||||||
| 13 points by jer0me a day ago | 6 comments | ||||||||
| ▲ | skissane a day ago | parent | next [-] | |||||||
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. | ||||||||
| ▲ | bradknowles 20 hours ago | parent | prev | next [-] | |||||||
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. | ||||||||
| ▲ | habitue 20 hours ago | parent | prev | next [-] | |||||||
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 | ||||||||
| ||||||||
| ▲ | canibalrex 9 hours ago | parent | prev | next [-] | |||||||
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. | ||||||||
| ▲ | perrygeo a day ago | parent | prev [-] | |||||||
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. | ||||||||