The drivers behind software delivery inefficiency
1–10 of 58 posts
Re: The drivers behind software delivery inefficiency
#2Great paper. QA's role in software is underrated.
Re: The drivers behind software delivery inefficiency
#3It'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.
Re: The drivers behind software delivery inefficiency
#4[flagged]
Re: The drivers behind software delivery inefficiency
#5It'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.
People are good at different things. Usually they like the things they are good at and vice versa. Different tasks require different mind sets and dev, QA and ops are vastly different in that regard.
That is why we have assembly line production in basically every industry except software.
Re: The drivers behind software delivery inefficiency
#6Great read. Learned the hard way that we need QA roles.
Re: The drivers behind software delivery inefficiency
#7It'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.
Entirely dependent on what you're shipping.
If there is a significant amount of user interaction to test, QA is going to do a better job than devs.
If there's a lot of integration behind the scenes with a ton of edge cases, devs will do a better job.
If you have both (probably), you need both teams to pitch in more than upper management wants to believe and they'll just cut you instead! :D
Re: The drivers behind software delivery inefficiency
#8It'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 interconnected for any developer to fully understand all of it because of years of building with unclear boundaries between teams. QA's value wasn't really the testing they did. The value was that we had a dedicated team who's job it was to see the big picture and keep up with the changes 15 different teams were making on the same product. Management wanted the benefits of removing QA without the pain of paying down all the organizational and tech debt that made them valuable.
Again, I agree with your sentiment, but also, I think that most large organizations are not willing to do the necessary work to get a place where QA can be removed.
Re: The drivers behind software delivery inefficiency
#9It'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.
> Removing QA makes developers care about production
And removing Product Managers makes devs care about the product. Therefore, we should strip away all roles apart from devs..?
These roles exist because the skill set is sufficiently large to justify a dedicated role. If you're a startup, sure - maybe it's better to be lean - but in a larger org, QA folks are worth the investment and can definitely help to spot things that devs may not otherwise catch themselves since they know the product intimately and likely learn of common pitfalls. The few QA folks I've worked with have been worth their weight in gold.
Re: The drivers behind software delivery inefficiency
#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 original empirical evidence. In other words, probably should've been a blog.