Re:Tasks, Lists, and Promises
by Jtsummers on Saturday May 21, 2022 @07:38PM
(#31463282)
It's amazing to me how many people struggle with the first issue she describes. If a task is blocked it doesn't matter that it's high priority, there is zero point in doing it because you can't actually do it. If it's blocked by a lower priority task, then elevate that task's priority and do it first (or earlier). This is project management 101, also called common sense.
[ Parent
| on HN ]
Re:Tasks, Lists, and Promises
by andreareina on Saturday May 21, 2022 @10:28PM
(#31464364)
I don't know these people but my presumption is that Rachel's colleagues are smart cookies. I figure it's less likely that a bunch of smart engineers don't understand dependency resolution and priority propagation, and more that there are (maybe imagined, maybe not) organizational factors that make it a problem to pick up a nominal p2 when there's a p0 on the board, factors that she can ignore due to political capital or just sheer IDGAF-ness.
Yep, priority inversion is how RTOSes handle the problem too.
It depends on your issue management system, but most offer some system (labels, tags, flags) which you can use to identify a blocked issue to be passed over without tweaking the priority directly. I'd favour using such a system over priority adjustments in most cases, because presumably when the task gets unblocked it should be seen to sooner than the "While we have time" task you were doing in the meantime.
Yup, got the same though after reading the first paragraph. Priorities should propagate transitively, obviously. Straw-man problem.
Not a straw man, it's a real thing. Some people really do not get that "high priority" doesn't equate with "can be done now". I have had to physically draw out dependencies to demonstrate why X should be put on the same priority as Y if they really want Y done, because X is blocking it (in some fashion).