Comment by onion2k
1 day ago
I'm pretty certain that the one factor above all others that makes software delivery slow down is doing too many things at once. You should aim to be working on one project at a time in your team.
Taking on another project, or workstream, or idea, or investigation in a team is pretty much entirely downside.
- more context switching, which means people get cranky faster
- lower bus factor for any piece of work, until its 1 dev per thing and that things stops of the dev isn't there
- lower people count on work means everything takes how long 1 person can do it (2 people is twice as fast for parallizable work)
- slower dependency resolution until something as basic as getting a PR reviewed is a big deal
- fewer people seeing the problem means less experience brought to bear, which reduces speed gains from having seen this stuff before
And more besides. For every project the goal should be maximum parallelism.
I've never really understood this opinion. For me there's plenty of times that some problem needs to be solved and simply banging my head against it isn't going to make it happen any faster. Having some easy low priority stuff to do for a bit (or a high priority short task that interrupts) seems to let my subconscious solve the issue in the background and keeps me happier and more motivated. If it was two difficult tasks that were supposed to be done in parallel maybe that would be different, but I've never seen anyone asking for that
Allowing for creative incubation is a real thing. But task restarting penalty is real as well: you lose context and your mental model; working memory loses details; dependencies are reverified unnecessarily; flow state momentum lost; environment reconstruction each time and similar administrative tasks, etc.
> low priority stuff to do for a bit (or a high priority short task that interrupts) seems to let my subconscious solve the issue in the background and keeps me happier and more motivated.
For a bit is ok. I had one month task, that was interrupted daily for over a year, that's how I got demotivated and burned out so much that I needed neurologist.
> two difficult tasks that were supposed to be done in parallel maybe that would be different, but I've never seen anyone asking for that.
Probably that's why you say interruptions are good, no experience of how bad can interruptions be.
My hand wavy math.
One person dedicated to a single project / task baseline 100% total output.
One person split between two tasks / projects that require context switching, 70% total output at best, perhaps 50% total output, a loss of 50%.
One person working on a single task that they’re passionate about / intrinsically motivated to complete: 150-500% output.
When you have one task / project to think about and focus on, it engages your brain: sleeping, showering, walking, your subconscious is processing.
Adding just one extra project / task that requires a context switch mostly kills this subconscious processing mechanism.
But if that person has rare skills where at least 25% of their output makes another team of 5 100% more effective (200%), than than loss of 50% output is actually a 33% gain in output!
Say you have a team of 6 (5+1 DevOps Wizard), and a team of 5. so Call it 5x200 +5 x100% output, 1500 output total. Split our wizard in half and you get 5x200 + 5x200 = 2000 output total!
At a certain minimum level the effectiveness inverts because people are waiting on wizard magic and everyone is less effective, but there is benefit to having specialists be split.
> You should aim to be working on one project at a time in your team.
You're swimming against the tide with this. AI pilled management is driving teams to deliver more parallel workstreams, not fewer, with fewer, AI-augmented devs taking them on.
Context switching isn't seen as a cost. AI is seen as the solution to the bus factor and experience problem. Same goes with the issue of dev capacity.
IMO it's deeply misguided but it's crystal clear where the winds are blowing.
It's funny, because LLMs have context switching costs too! Cached tokens cost less than non-cached. There's no reason to think that doesn't apply to humans.
I’ve genuinely found that context switching is a skill like any other. When I first started using LLMs and context switching doing 5-10 different work streams at once I was utterly, utterly exhausted at the end of each day.
Now many months in, it doesn’t feel nearly as taxing.
Maybe this is in no small part due to LLMs improving enough you don’t have to spend as much mental energy reviewing their output and them being better at managing worktrees and other tedium, but the idea of doing lots of things at once feels like a mental muscle that was previously weak and has gained in strength in ways I never though possible for me.
5-10 feels like a lot. I can reliably maintain hands on 2-4 separate work streams. I still need to maintain a pretty close eye on changes to our system, as I’m one of 2 devs. I’ve tried doing 5+ things at once and I just cannot get it to work. I think I move faster when I’m more involved anyhow, since I have adequate “mini-context” of what each operation is.
1 reply →
And this is why software consultancies always recommend a “Digital Transformation Project” to hire as many remote people as possible, all being paid peanuts and charged out at $1500+ per day, the added bonus being the project will take an infinite amount of time!
I struggle to believe people above me where I work refer to these leaches as “our partners” it seems mad to me.
One project at a time? How on earth can that possibly work? I always ask to have multiple projects to work on, because getting blocked is a real thing, and having other work you can still pursue will ensure you keep things moving! Perhaps my definition of project is very different from yours?
I am friendly with a project manager at work - he's overseeing a fairly big modernisation project with lots of stakeholders, lots of moving parts, lots of direct reports, and while he seems to have a lot of long lunches, he makes sure that no one working on the project is blocked - he'll do everything he needs to to unblock people - regular meetings to hear about blockers, chase down approvers, just tell his direct reports to do something without approval (as long as it's not something bad) and he'll deal with the consequences. But most people are not this dedicated unfortunately.
Single Piece Flow fits with other Toyota ideas of how to get high quality work done. If something is frequently blocking the line, the solution is to put resources toward the bottleneck, not spin up more work in parallel.
Building software isn't the same as building cars. Some ideas needs months or years to be realized, and there's only so fast you can realistically move.
2 replies →
Projects can be broken down into parallel pieces of work, so you should always be able to pick up another part of the project rather than switch to a different project if you're blocked. As the other poster says, the goal is to not be blocked though. The leadership team need to support the delivery team to get the work done as a focused flow of items with as little blocking and waiting time as possible. If you're getting blocked, that's a signal that the org is failing.
Admittedly this is a little idealistic, but if it's not the goal then the reality is always far worse.
That's why I say the definition is "project" is key to this.
And what about investigating and fixing bugs? Bug reports don't come in on a schedule, and they're necessarily interrupt-driven unless you just don't care about your customers.