2 ms·

What do I care about start to finish time? The only way to shorten that latency would be to have so many employees that they can all spend all day just waiting

What do I care about start to finish time? The only way to shorten that latency would be to have so many employees that they can all spend all day just waiting to pounce immediately on their inbox. It's just the same or worse waste distributed differently. A developer with a full pipeline seems the most efficient to me. Let there be 15 projects all in different stages of progress. It's fundamentally not a synchronous process and I say a mistake to try to make it one. Edit to address a sense I'm getting from several comments at once, that I may be a manager who doesn't understand or care about developers: I AM the developer (& sysadmin) with a bunch of fresh and stale projects and it doesn't bother me at all. I always have work to do but it's not stressfull because that is about your boss(es) not about the number of open items. If anyone tried to say all that stuff needs to be done yesterday, sure that would be a problem. But all they really are is a spectrum of priorities. Some are just ideas little more than stubs for possible future interest, some would be nice but may never be justifiable in a strict easily quanifiable sense, you can't bill any customer for the hours, and yet would still be nice, would be one of the things that sets your product apart and attracts the customer in the first place, and some have normal priority, and when something high priority comes along, it simply displaces the rest. It just requires a boss who doesn't say that every single new item is always the most important. That stack of available projects, and the age of half of them, doesn't bother me at all. Half the time, a different project is as good as a walk in the park for the reset / fresh look factor when stuck on something.

kqr 5y ago
This is a common conflict! One perspective says that idle engineers cost money, so you should load up your engineers to 99 % utilisation with a huge backlog of tasks. The consequence of this is that tasks take, on average, months to complete because they sit idle most of the time, not being worked on. The other perspective is that idle tasks is what's expensive. Thus you must keep your engineers lightly loaded (say 70 %) so they can, in your words, pounce on new tasks. With this setup, most tasks spend a negligible time waiting and most time actively worked on. Now, how can idle tasks be more expensive than idle engineers? There are whole books dedicated to explaining this. I'd recommend starting with Reinertsen's Principles of Product Development Flow.
- thraxil 5y ago
  It's always kind of amazing that so many engineers (and engineers turned manager) have encountered enough queuing theory to understand that if they keep a CPU at 99% utilization, it will have a detrimental effect on task latency, but can't understand how to apply that same reasoning to engineer utilization.
  - Brian_K_White 4y ago
    An engineer knows where analogies apply and where they don't. My pool of available work is not impacting whatever I happen to be working on at the moment. I am not doing 1 second of work on 60 different projects every minute.
dcow 5y ago
Some developers are very much not efficient in a "fully pipelined" stage. Lots of context switching can slow down everything in the pipeline. Even if you're waiting on a code review and burn a few hours, it can still be more efficient to stay focused on driving the task at hand to completion than trying to spin up a small task during that time and switching back to respond to review comments every so often.
lordnacho 5y ago
You need idle time as an engineer. Otherwise if a higher value item appears in the pipeline after a lower value item you'll be working on the lower value thing first. Idle time is also where you do useful things like checking for updated dependencies, running a linter, generally reading up on the tech you're using, and making the code ready for future edits. Not so idle at all but not really the same as working on a ticket either.
- the_jeremy 5y ago
  Do you work somewhere that gives you this idle time? We explicitly have tickets for any tech debt or dependency updates we need to do, because otherwise we don't get time to do that.
  - lordnacho 5y ago
    I decide my own work so yeah. I realise not everyone gets that luxury.
Brian_K_White 5y ago
I take my idle time whenever I want, either by simply not working right then, or working on something low priority that I just want to work on. The size of my pool of available projects has no bearing on that positive or negative.

kqr 5y ago

This is a common conflict! One perspective says that idle engineers cost money, so you should load up your engineers to 99 % utilisation with a huge backlog of tasks. The consequence of this is that tasks take, on average, months to complete because they sit idle most of the time, not being worked on. The other perspective is that idle tasks is what's expensive. Thus you must keep your engineers lightly loaded (say 70 %) so they can, in your words, pounce on new tasks. With this setup, most tasks spend a negligible time waiting and most time actively worked on. Now, how can idle tasks be more expensive than idle engineers? There are whole books dedicated to explaining this. I'd recommend starting with Reinertsen's Principles of Product Development Flow.

thraxil 5y ago
It's always kind of amazing that so many engineers (and engineers turned manager) have encountered enough queuing theory to understand that if they keep a CPU at 99% utilization, it will have a detrimental effect on task latency, but can't understand how to apply that same reasoning to engineer utilization.
- Brian_K_White 4y ago
  An engineer knows where analogies apply and where they don't. My pool of available work is not impacting whatever I happen to be working on at the moment. I am not doing 1 second of work on 60 different projects every minute.

dcow 5y ago

Some developers are very much not efficient in a "fully pipelined" stage. Lots of context switching can slow down everything in the pipeline. Even if you're waiting on a code review and burn a few hours, it can still be more efficient to stay focused on driving the task at hand to completion than trying to spin up a small task during that time and switching back to respond to review comments every so often.

lordnacho 5y ago

You need idle time as an engineer. Otherwise if a higher value item appears in the pipeline after a lower value item you'll be working on the lower value thing first. Idle time is also where you do useful things like checking for updated dependencies, running a linter, generally reading up on the tech you're using, and making the code ready for future edits. Not so idle at all but not really the same as working on a ticket either.

the_jeremy 5y ago
Do you work somewhere that gives you this idle time? We explicitly have tickets for any tech debt or dependency updates we need to do, because otherwise we don't get time to do that.
- lordnacho 5y ago
  I decide my own work so yeah. I realise not everyone gets that luxury.

Brian_K_White 5y ago

I take my idle time whenever I want, either by simply not working right then, or working on something low priority that I just want to work on. The size of my pool of available projects has no bearing on that positive or negative.