Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The drivers behind software delivery inefficiency

dl.acm.org

Post reply on HN
Print view View original

21–30 of 58 posts

Re: The drivers behind software delivery inefficiency

#21

Post by antihero »

unknownfuture wrote: post #19
onion2k wrote: post #16

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…

> 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 misgui…

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.

Re: The drivers behind software delivery inefficiency

#22

Post by QuercusMax »

onion2k wrote: post #16

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…

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?

Re: The drivers behind software delivery inefficiency

#23

Post by regularfry »

For us, review latency was obviously a problem so we eliminated it (for most tickets, anyway) by making the handover synchronous. Get on a call with the reviewer when it goes into the review column. The win from eliminating review latency massively outweighs the context switch cost for the reviewer. All the more so when the patch is small enough to actually read through on the call, so if there is anything immediate to address you can ping-pong it without anything waiting.

Re: The drivers behind software delivery inefficiency

#24

Post by xxpor »

unknownfuture wrote: post #19
onion2k wrote: post #16

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…

> 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 misgui…

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.

Re: The drivers behind software delivery inefficiency

#25

Post by datadrivenangel »

brotchie wrote: post #17
onion2k wrote: post #16

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…

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…

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.

Re: The drivers behind software delivery inefficiency

#27

Post by transitorykris »

QuercusMax wrote: post #22
onion2k wrote: post #16

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…

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?

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.

Re: The drivers behind software delivery inefficiency

#28

Post by dijit »

akkartik wrote: post #26

"Stop blaming QA.." What year is it?! Does anyone still blame QA?! If so, please consult the calendar and enter the 21st century!

Do people still hire QA?

Over the last 16 years all I've seen is people implying (heavily) that they can replace QA with "good enough unit tests"..

Which then inevitably leads to bugs, and performance regressions and developers doing their own QA.

I honestly think that all of this is a psyop to get devs to do more, that and "devops" which is either rebranded sysadmins, or developers working as yaml monkeys between code reviews and feature development.

Re: The drivers behind software delivery inefficiency

#29

Post by akkartik »

dijit wrote: post #28
akkartik wrote: post #26

"Stop blaming QA.." What year is it?! Does anyone still blame QA?! If so, please consult the calendar and enter the 21st century!

Do people still hire QA? Over the last 16 years all I've seen is people implying (heavily) that they can replace QA with "good enough unit tests".. Which then inevitably leads to bugs, and performance regressions and developers doing their own QA. I honestly think that all of this is a psyop to get devs to do more, that and "devops" which is either rebranded sysadmins, or developers working as yaml monkeys between co…

Yeah I've seen both approaches. Either teams do their own QA or we have a dedicated function. Depends on the domain to some extent. Both can work. But I don't hear people saying stupid shit anymore like "QA is a cost center". When we have it, everyone understands the value.

Re: The drivers behind software delivery inefficiency

#30

Post by QuercusMax »

transitorykris wrote: post #27
QuercusMax wrote: post #22

Earlier quoted context omitted.

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?

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.
Post reply on HN