The drivers behind software delivery inefficiency • Hacker News Board

Re: The drivers behind software delivery inefficiency

#51

Post by QuercusMax » Tue, Jul 21, 2026, 2:29 PM UTC

jurgenburgen wrote: post #50

QuercusMax wrote: post #30

Earlier quoted context omitted.

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.

When is multi-tasking ever productive? The biggest time sink is understanding the problem. I can’t understand two different problems at the same time.

How did you manage to go to school and handle multiple subjects at the same time? It's exactly the same thing.

I'm not talking about multitasking on a moment by moment basis. I'm talking about over the course of a day or week you have multiple reponsibilities. That's the most normal thing ever.

For example, current projects I'm working on include:

  - Babysitting a weeks-long data migration
  - Designing a better storage system for some parts our data
  - Implementing data cleanup for customers who have offboarded
  - Code hygiene improvements across the codebase to support static analyzers
  - Planning committee work for upcoming hackathon

And that's just me - I'm not even a team lead. Other people on my team are working on different things within our team scope.

Re: The drivers behind software delivery inefficiency

#52

Post by QuantumGood » Tue, Jul 21, 2026, 3:07 PM UTC

retatop wrote: post #31

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…

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

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.

Re: The drivers behind software delivery inefficiency

#53

Post by QuercusMax » Tue, Jul 21, 2026, 3:08 PM UTC

onion2k wrote: post #36

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?

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

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.

Re: The drivers behind software delivery inefficiency

#54

Post by specialist » Tue, Jul 21, 2026, 8:42 PM UTC

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.

For troubleshooting, esp blockers, I totally agree.

Re: The drivers behind software delivery inefficiency

#55

Post by specialist » Tue, Jul 21, 2026, 8:47 PM UTC

jamesfinlayson wrote: post #39

akkartik wrote: post #29

Earlier quoted context omitted.

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.

I worked in a team with no QAs for a while - testing was done by developers and there were a lot end to end tests. It worked pretty well - I think a couple of small bugs got through, but whether a QA would have found the issues is debatable. It was for an internal system too so the cost of a defect was low anyway. I've also worked a company with no QAs in some pretty core teams and they had almost no defects either.…

> It was for an internal system too...

Ya, in that case, IMHO, self QA can be fine.

Customer facing products (deliverables) need QA/Test. Again, IMHO.

Re: The drivers behind software delivery inefficiency

#56

Post by vasco » Wed, Jul 22, 2026, 6:28 AM UTC

Corvyn wrote: post #42

vasco wrote: post #3

It's hard to believe something when I saw the opposite work in practice. Removing QA makes developers care about production. You can say now they are wasting part of their time doing what QA did but to me it's not wasted time. Incidents went down both times I saw it happen, and stayed down.

I struggle with this question a lot: when does specialization make a team better, and when does it start to erode ownership? When I first joined Amazon, my team had no dedicated QA, Product Manager, Technical Program Manager, or frontline support team. I had come from a startup where none of those roles existed either, so it felt normal. Engineers also carried the pager and dealt directly with the operational consequ…

You cannot outsource quality to another role, or you can but you'll be slower and have more bugs.

Re: The drivers behind software delivery inefficiency

#57

Post by regularfry » Wed, Jul 22, 2026, 8:14 AM UTC

dickersnoodle wrote: post #49

regularfry wrote: post #48

Earlier quoted context omitted.

That is the context switch I'm referring to. It's worth the reviewer suffering a 15 minute (say) flow state loss to avoid the multiple hours the ticket would otherwise have been waiting to be picked up.

Worth it to who?

The team. The organisation. The reviewer, if they care about team throughput.

Re: The drivers behind software delivery inefficiency

#58

Post by agumonkey » Sun, Jul 26, 2026, 8:22 AM UTC

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…

[dead]