3 ms·

Does it make sense to degrade the performance of good software teams because bad software teams exist? Ideally we’d always have good software teams, but in the

Does it make sense to degrade the performance of good software teams because bad software teams exist? Ideally we’d always have good software teams, but in the real world sometimes you have to build software with bad teams. Leaders have options, they can do things like reduce scope, increase budget, increase schedule, or full on abandon or cancel the project. These are all options available to leaders, but they require tradeoffs and decisions to be made on a project by project basis. It is scalable to have a strict process that everyone has to follow, then impose a watchdog to enforce it on a wide scale. It may not be better to have separate QA, but it is easier for those in charge.

ethbr1 3y ago
It makes the most sense to me to match the org structure to the teams you have. If I'm trying to build something with undertrained, demoralized, underpaid engineers... it's not optimal to use methods intended for self-motivated, high-performance teams. And nothing says there must be company-wide mandates. Maybe this area gets a formal, independent QA team, but this other area doesn't. My experience just doesn't bear out that collapsing the QA function into development always leads to better outcomes. I've seen the opposite happen too often, and QA be the sole bulwark between idiocy and customers.
bb88 3y ago
> Ideally we’d always have good software teams, but in the real world sometimes you have to build software with bad teams. Here's a real, perhaps unexpected counterpoint. Say you have a good software team. How do they build good software with bad management?
- xyzzy_plugh 3y ago
  They quit.
  - bb88 3y ago
    Exactly!
- iancmceachern 3y ago
  Quit and do it for someone else
fzingle 3y ago
> Does it make sense to degrade the performance of good software teams because bad software teams exist? Consider the classic statistic "most drivers think they are above average". I posit that the same is true of software teams, almost every team will self-assess as above average, i.e. good. Those teams will then imagine that, being good, they build quality into the process and very little verification QA is done. I have worked as a software consultant for 15 years now. I've worked with at least 40 separate software teams in that time. Every single team manager would pep talk with "this is the best team I've ever seen". Some of this is obviously blowing smoke to get people to work harder and feel good. But over the years I've had candid conversations with managers and realized that most of the time the genuinely think their team is really good, truly top 10-20%. Here's the rub. Being a consultant, I'm almost always brought in by higher level management because something is going horribly wrong. The team can't deliver quickly. The software they deliver is bug ridden. They routinely deliver the wrong software (i.e. incorrect interpretation of requirements.) Often times these problems are not only the fault of the development team, management has issues too. But in every single case, the development team is in dire straits. They have continuous integration sure, and unit tests, and nightly builds, and lots of green check marks. But the unit tests test that the test works. The stress tests have no reality based basis for expected load. The continuous integration system builds software but it can't be deployed in that form for x, y & z reasons, so production has a special build system, etc... In 15 years I have never once encountered a team that would not benefit from a QA team doing boring, old school, black box manual testing. And the teams that most adamantly refuse to accept that reality are precisely those that think they are really top tier because they have 90+% unit test coverage, use agile and do nightly builds. So, my question is, do you (I don't mean the specific "you" here, rather everyone should ask themselves this, all the time) think that most bad software teams know they are bad? Including the one you are part of? Would it really hurt to have some ye olde QA, just in case, you know, you are actually just average? :)
- shiroiuma 3y ago
  I'm curious: in your many years of being a consultant to these bad teams, where the manager really thought they were top 20%, did you get a chance to talk to the rank-and-file team members, and did they paint a very different picture of the team health and software quality than their manager? Also, did you run across any orgs where they basically refused to use a process like Agile, and instead just did ad-hoc coding, insisting that this was the best way since it worked just fine for them back when they were a 5-person startup?

ethbr1 3y ago

It makes the most sense to me to match the org structure to the teams you have. If I'm trying to build something with undertrained, demoralized, underpaid engineers... it's not optimal to use methods intended for self-motivated, high-performance teams. And nothing says there must be company-wide mandates. Maybe this area gets a formal, independent QA team, but this other area doesn't. My experience just doesn't bear out that collapsing the QA function into development always leads to better outcomes. I've seen the opposite happen too often, and QA be the sole bulwark between idiocy and customers.

bb88 3y ago

> Ideally we’d always have good software teams, but in the real world sometimes you have to build software with bad teams. Here's a real, perhaps unexpected counterpoint. Say you have a good software team. How do they build good software with bad management?

xyzzy_plugh 3y ago
They quit.
- bb88 3y ago
  Exactly!
iancmceachern 3y ago
Quit and do it for someone else

fzingle 3y ago

> Does it make sense to degrade the performance of good software teams because bad software teams exist? Consider the classic statistic "most drivers think they are above average". I posit that the same is true of software teams, almost every team will self-assess as above average, i.e. good. Those teams will then imagine that, being good, they build quality into the process and very little verification QA is done. I have worked as a software consultant for 15 years now. I've worked with at least 40 separate software teams in that time. Every single team manager would pep talk with "this is the best team I've ever seen". Some of this is obviously blowing smoke to get people to work harder and feel good. But over the years I've had candid conversations with managers and realized that most of the time the genuinely think their team is really good, truly top 10-20%. Here's the rub. Being a consultant, I'm almost always brought in by higher level management because something is going horribly wrong. The team can't deliver quickly. The software they deliver is bug ridden. They routinely deliver the wrong software (i.e. incorrect interpretation of requirements.) Often times these problems are not only the fault of the development team, management has issues too. But in every single case, the development team is in dire straits. They have continuous integration sure, and unit tests, and nightly builds, and lots of green check marks. But the unit tests test that the test works. The stress tests have no reality based basis for expected load. The continuous integration system builds software but it can't be deployed in that form for x, y & z reasons, so production has a special build system, etc... In 15 years I have never once encountered a team that would not benefit from a QA team doing boring, old school, black box manual testing. And the teams that most adamantly refuse to accept that reality are precisely those that think they are really top tier because they have 90+% unit test coverage, use agile and do nightly builds. So, my question is, do you (I don't mean the specific "you" here, rather everyone should ask themselves this, all the time) think that most bad software teams know they are bad? Including the one you are part of? Would it really hurt to have some ye olde QA, just in case, you know, you are actually just average? :)

shiroiuma 3y ago
I'm curious: in your many years of being a consultant to these bad teams, where the manager really thought they were top 20%, did you get a chance to talk to the rank-and-file team members, and did they paint a very different picture of the team health and software quality than their manager? Also, did you run across any orgs where they basically refused to use a process like Agile, and instead just did ad-hoc coding, insisting that this was the best way since it worked just fine for them back when they were a 5-person startup?