4 ms·
This queue analogy doesn't quite reflect the behavior of queues of development tasks versus queues of customers waiting to get a Bagel. The Bagel queue is stri
by derriz 4y ago
This queue analogy doesn't quite reflect the behavior of queues of development tasks versus queues of customers waiting to get a Bagel.
The Bagel queue is strictly FIFO - while work queues generally operate more like a priority queue. This means that a long queue of development tasks may not actually be all that damaging to the business as many of the the items may be low-priority items and the high-impact items may still have low cycle times.
Also the "specification rot" issue is not always a problem. The priority of a task may not be well known when it arrives in the queue - over time its priority becomes clearer (i.e. it's realised that the feature/task isn't actually very important) so unnecessary work can be saved.
Under-utilization is rarely a problem either. It's not like software engineers will just sit around doing nothing even if the official business-facing work queue is empty. There are always some implicit low-priority tasks which engineers will tackle even if the official business-facing work queue appears empty: refactoring, research, build-system improvements, source-code hygiene, etc.
- lucasfcosta 4y agoAuthor here. That's a very good comment. Thank you. With regards to task queues not being FIFO, they aren't indeed. However, even when you don't have a FIFO queue, a long queue with shifting priorities will cause cycle-times to become even more unpredictable as you'll be reshuffling the queue with time. You should definitely reshuffle and ruthlessly prioritise, but you should also "tail drop" old items and try to create new ones "just in time".
- Zenst 4y agoWhich reminds me of the old engineering trick of saying it will take longer than it does as managing expectations is an art best explained by Scotty - https://www.youtube.com/watch?v=8xRqXYsksFg https://www.youtube.com/watch?v=8xRqXYsksFg
- derriz 4y agoThanks for the thought-provoking article. I think I agree with the conclusions even if the analogy isn't perfect. The connotations of under-utilization or over-provision are often negative - particularly in management - but I think as you point out are necessary in order to provide any sort of quality of service. Qualitatively/subjectively, when I think about the times I've worked as an engineer in an "always busy" environment, I believe that I was often less productive - it's like you need space to breathe. It was certainly less rewarding as it was never possible to be as responsive as you'd like to requests.