2 ms·
This article is very thorough, but makes one fairly big mistake: it assumes there is low variability in task size. This could be a reasonable assumption if you
by kqr 4y ago
This article is very thorough, but makes one fairly big mistake: it assumes there is low variability in task size.
This could be a reasonable assumption if you're very good at adjusting scope, but I would be skeptical unless you have measured it and have the numbers to prove that in practise, tasks indeed turn out to be roughly the same size (±20 % or whatever -- I don't know the exact threshold.)
Why this matters is that under cheap context switches and even modest task size variability, it's -- surprisingly -- a performant queuing policy to pre-empt the currently processing task to handle every incoming task. The intuition behind this is that if a task is still processing when a new one comes in, it's likely to be a "big" task, and it's worth letting small tasks ahead in line. Reduces mean response time.
Of course, this could all be moot anyway because context switches are certainly not cheap for software engineers. I just thought I should mention it for nuance. Rules of thumb only get you so far, at some point you have to more accurately model the situation and simulate.
- vladgiverts 4y agoSpeaking to the task size point, I’ve found (via leading a number of teams and training many more team leads) it’s possible to decompose any task into smaller tasks so that every task is within a small constant factor of each other. If it seems impossible for a given task, maybe because it’s particularly complex or has lots of unknowns, then no problem, simply create a “spike” task to research or prototype whatever you need to in order to decompose the big task into appropriately sized chunks (for your team’s idea of appropriate). See you end up with a bunch of tasks that are all roughly the same size or are spikes of similar size, and you can have the very nice predictability and productivity that the author is speaking about. (btw, I also agree that contact switches are never cheap for software developers, so it’s better to let them finish whatever they’re working on whenever it’s not too unreasonable to allow it)
- kqr 4y agoThis has been true in my personal research too. When projects are sufficiently decomposed, a "ticket" about implementing part of a project is generally speaking within the same order of magnitude. However, this article is not talking about "tickets" but rather about the entire project. So that you may or may not be able to break the project down into roughly-constant chunks is irrelevant for the arguments of this article. What matters is the size of the full project that you need to see through from start to finish in order to get business value out of your work. (Yes, you can usually break down the project into smaller chunks too, so that you see business value quicker. However, these are rarely of constant size anymore, in my experience.)
- 8n4vidtmkvmk 4y agoyou have to be careful about pushing out an early MVP for "business value". my company tends to do this but the MVPs are so far from complete that I'm skeptical we're even getting good data out of it
- vaidhy 4y agoThis assumes that tasks can be defined as small and large ahead of starting them which goes back to a similar mistake that you pointed out - our estimates need to be true and have high confidence. Estimates for tasks have high variance and some of them will turn out to be inordinately complex, though not clear at first. Second one is that it assumes all tasks are of same priority and the utility of all tasks are equal. Both of them are not true for software tasks. The assumptions behind the queueing policy are not true here.
- kqr 4y agoOne of the neat things about the "always pre-empt the currently processing task" is that you don't need to know the size of any task! All you need to know is that it's variable, which you can find out from past data.