3 ms·
Huh, this is a pretty salient observation. I'm curious about the extent to which it applies -- I certainly am a stack-person some times, and a queue-person at o
by johnloeber 12y ago
Huh, this is a pretty salient observation. I'm curious about the extent to which it applies -- I certainly am a stack-person some times, and a queue-person at other times. Could it depend on context? Queue for important tasks, Stack for unimportant tasks?
- userbinator 12y agoMaybe you're more of a "priority queue"?
- johnlbevan2 12y agoI wouldn't put unimportant tasks in the stack; that would mean you do those first. Fast turnaround tasks are best for the stack. Tasks which involve multiple parties & thus planning and coordinating are best for the queue. Many organisations already deal with this in having first line and second line support; first line pick off the quick stuff and log the hard stuff; second line then work their way through the hard stuff/ First line will also put a task on hold if a new call comes in; their priority is to answer the phones/get things logged, with working on resolutions taking lower priority. So first line support's a stack, second line's a queue. As the blogger mentions though, generally things are mixed; whilst there will be a preference/default working style most people/teams will fall somewhere in between, usually adding some level of prioritisation. Another point is that prioritisation is generally based solely on the importance of the task & detailed analysis of its implications for queue people, whilst stack people will tend to guess at both the importance and the implementation time to get a priority based on the weightings of both factors.