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

31–40 of 58 posts

Re: The drivers behind software delivery inefficiency

#31

Post by retatop »

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 tasks that were supposed to be done in parallel maybe that would be different, but I've never seen anyone asking for that

Re: The drivers behind software delivery inefficiency

#32

Post by 4lx87 »

regularfry wrote: post #23

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…

> Get on a call with the reviewer when it goes into the review column.

The context switch cost is simply moved to the reviewer, who presumably was working on something. It’s net the same result.

Re: The drivers behind software delivery inefficiency

#33

Post by NichoPaolucci »

antihero wrote: post #21
unknownfuture wrote: post #19

Earlier quoted context omitted.

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

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.

Re: The drivers behind software delivery inefficiency

#34

Post by BobbyTables2 »

In my experience, things head south when managers see “feature X requires 4 person-months effort” and then assign 4 people to work on it, with 2-3 being junior, and the remaining multiplexed with other tasks. They think this will allow them to meet their goal of being feature complete in a month.

There ends up being no shared vision of how it all works. Disparate pieces are developed and some poor sap ends up gluing them together in a painful manner, 2-3 months later. QA finds some edge cases, driving last minute fixes and delaying release.

Ultimately more difficult bugs escaped QA and go on to result in customer escalations.

Eventually, the feature gets cleaned up a year or two later, after another month or two of development effort.

Customers just see a broken feature for 2-3 years and give up on it.

So. Much. Waste.

It’s not about having a Chief Navel-Gazer Architect. Development on a shared code base is just not as parallelizable as one would desire.

One has to thoroughly understand exactly what they are doing and know all the relevant considerations. It isn’t practical for a group to all be capable of such for every feature. And nobody is going to take the time to write a detailed internal API spec that would even allow such to be possible…

Re: The drivers behind software delivery inefficiency

#35

Post by 0xbadcafebee »

> Organizations needs to prioritize measuring for these inefficiencies that lowers the quality bar, churn software engineers, and slow down delivery process. Once measured, organizations should add mechanism, both technical and procedural to limit the waste

Organizations can't even track and improve on sprint performance. They aren't gonna track and improve inefficiencies either, because they have no motivation to improve. Even if they're losing money and customers due to their product sucking, they still won't see those inefficiencies as the cause of their problems. They'll instead imagine that what they really need is to push more sales/increase initial subscriptions, or add a killer new feature they have no time to implement, or pivot to a different business model. But their lack of rigor is only partly due to executive stupidity; the other part is mediocrity. If you have lazy, ignorant devs, you're gonna have lazy, ignorant process, leading to all the waste.

Re: The drivers behind software delivery inefficiency

#36

Post by onion2k »

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?

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.

Re: The drivers behind software delivery inefficiency

#37

Post by jamesfinlayson »

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?

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.

Re: The drivers behind software delivery inefficiency

#38

Post by jamesfinlayson »

BobbyTables2 wrote: post #34

In my experience, things head south when managers see “feature X requires 4 person-months effort” and then assign 4 people to work on it, with 2-3 being junior, and the remaining multiplexed with other tasks. They think this will allow them to meet their goal of being feature complete in a month. There ends up being no shared vision of how it all works. Disparate pieces are developed and some poor sap ends up gluing…

Layer on the merge conflicts resulting from this fun scenario...

Re: The drivers behind software delivery inefficiency

#39

Post by jamesfinlayson »

akkartik wrote: post #29
dijit wrote: post #28

Earlier quoted context omitted.

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.

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.

Currently working on some legacy stuff with no proper end to end tests and I'm very grateful for competent testers right now.

Re: The drivers behind software delivery inefficiency

#40

Post by jamesfinlayson »

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…

> "good enough unit tests"

Good enough end to end tests then maybe.

Post reply on HN