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

11–20 of 58 posts

Re: The drivers behind software delivery inefficiency

#11

Post by mawadev »

jackb4040 wrote: post #10

> "When coupling getting higher, considerable amount of time is wasted in heavy coordination, alignment, and shared strategy. The other side of the same coin, considerable amount of time is lost when one component breaks for everyone" Is this slop, or poor english skills? Is there any peer review barrier to being published here? Because this kind of looks like a low-effort 4-page survey of other people's data with no…

I was quite shocked to witness a watchmojo Top 5 drivers behind software delivery inefficiencies kind of research paper

Re: The drivers behind software delivery inefficiency

#12

Post by MASNeo »

superfrank wrote: post #8
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.

Just to offer a different perspective, my last job removed QA and it was a nightmare. Feature delivery slowed way down and incidents and bugs went way up to the point where we started losing customers. In theory, I agree with what you're saying, but I think a codebase needs to be in a certain state and a company's leadership needs to be in a certain mindset to make it work. Our codebase was far too large and intercon…

Sounds just like every regular software project. That’s why cutting QA is a bad idea for every regular software project. Same goes for product management, unless you are Google and can afford building products people don’t need.

Re: The drivers behind software delivery inefficiency

#13

Post by delusional »

jackb4040 wrote: post #10

> "When coupling getting higher, considerable amount of time is wasted in heavy coordination, alignment, and shared strategy. The other side of the same coin, considerable amount of time is lost when one component breaks for everyone" Is this slop, or poor english skills? Is there any peer review barrier to being published here? Because this kind of looks like a low-effort 4-page survey of other people's data with no…

It's an article in an official publication. It's like a "letter to the editor" of a scientific journal, and has always been published alongside the more fact based research reports. People were posting "blog posts" in journals long before "blogs" were a thing. Part of the idea of a journal is exactly, like a newspaper, to exercise editorial control over what sorts of discussions they decide to include in each issue.

Science isn't just cold reports on aimless facts. You're supposed to discuss with your peers.

Re: The drivers behind software delivery inefficiency

#14

Post by thinkindie »

superfrank wrote: post #8
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.

Just to offer a different perspective, my last job removed QA and it was a nightmare. Feature delivery slowed way down and incidents and bugs went way up to the point where we started losing customers. In theory, I agree with what you're saying, but I think a codebase needs to be in a certain state and a company's leadership needs to be in a certain mindset to make it work. Our codebase was far too large and intercon…

We’ve never had a QA because we are on a tight budget but our PM is acting as a gatekeeper before declaring something as done.

However, there were too many cases that things were delivered as “ready” when they were not. PR review was not enough as everyone were checking diffs from GitHub only.

I implemented an intermediate step where the responsible engineer must post a screenshot or a short video of the ticket before passing to the PM and that alone resolved a lot of issues before they materialized on customers screens, just because you must take the extra effort to work on a proof of work.

Re: The drivers behind software delivery inefficiency

#15

Post by purrcat259 »

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 agree. I saw the same.

Hold up... We saw it at the same place :D

Re: The drivers behind software delivery inefficiency

#16

Post by onion2k »

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.

Re: The drivers behind software delivery inefficiency

#17

Post by brotchie »

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 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.

Re: The drivers behind software delivery inefficiency

#18

Post by QuercusMax »

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.

Really depends on what you're having QA folks do.

Writing automated end-to-end tests? Those are very often best done by those writing the software, with assistance from experts who know how to effectively build test infrastructure. I've very rarely seen them done effectively by QA or "test engineering" folks.

Running manual test scripts and torture testing the UI to break it in new and unusual ways? Definitely get dedicated testing / QA folks. It's very easy to be blind to how others might use the software, especially if you wrote it.

Re: The drivers behind software delivery inefficiency

#19

Post by unknownfuture »

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 misguided but it's crystal clear where the winds are blowing.

Re: The drivers behind software delivery inefficiency

#20

Post by andy_ppp »

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…

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.

Post reply on HN