Why Software Delivery Fails: The Hidden Drivers of Inefficiency
The drivers behind software delivery inefficiency
I explore the root causes behind software delivery inefficiency, revealing how organizational hurdles and process gaps slow down innovation. By analyzing real-world data, I highlight the critical barriers teams face and offer actionable insights to streamline workflows and boost productivity without relying on complex tools.
The biggest bottleneck in software delivery is not the code itself, but the invisible friction between teams and processes.
- 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.
- 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.
- 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…
- akkartik
"Stop blaming QA.."
What year is it?! Does anyone still blame QA?! If so, please consult the calendar and enter the 21st century!
- jackb4040
> "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 original empirical evidence. In other words, probably should've been a blog.