3 ms·

In his world, testing the software belongs to a different team than the implementation. Differently managed, differently staffed. Not with engineers, but with t

In his world, testing the software belongs to a different team than the implementation. Differently managed, differently staffed. Not with engineers, but with testers. It's difficult to say the least to move from testing into engineering And you can't just redefine Agile like that. It's the businesses' money, culture, and productive means. Not yours. If they want teetering software stacks with no thought given to maintainability, managed by non-tech-savvy staff, then that's what their money will buy. We enjoy an environment catering to our needs because our orgs can afford to throw a lot more resources at better managers and better talent. As a result individual contributors can contribute not just tickets, but also to help improve the way we work. Not possible in heavily top-down org structures.

Pxtl 5y ago
In my experience, splitting the testing team out of development materializes refactoring as costly. "What parts of the system did this impact?" "Well, this is a core piece of our ORM config, so... the entire data layer, so from a functional perspective this change impacts every part of the system" "Then you're not changing it, QA can't rerun all their old tests, it would take months, most of those tests don't even work anymore". End result: refactoring never happens. Get it right the first time.
- vinceguidry 5y ago
  Naturally. In an Agile environment it's more or less impossible to get it right the first time without seriously forward-thinking architecture, which takes time that could be spent pushing harder towards the deadline. It's a business decision to organize software production this way. Refactoring and ease of software maintenance are quality of life issues for engineers. Not business concerns.
alistairSH 5y ago
Ugh. I haven’t worked with an independent QA team in 15 years or so; testing is the responsibility of the dev team and there are test engineers on each team to facilitate that. Maybe this is a difference of building a product vs contracting? We have to keep what we build running for years; there is no turnover to a client where can declare the system “done”. As for redefining agile, I’ve done no such thing. The agile manifesto calls for working software. It calls for collaboration. Avoiding knowledge sharing amongst team members and throwing software over the fence to a remote test team are both counter to that goal (in my experience).

Pxtl 5y ago

In my experience, splitting the testing team out of development materializes refactoring as costly. "What parts of the system did this impact?" "Well, this is a core piece of our ORM config, so... the entire data layer, so from a functional perspective this change impacts every part of the system" "Then you're not changing it, QA can't rerun all their old tests, it would take months, most of those tests don't even work anymore". End result: refactoring never happens. Get it right the first time.

vinceguidry 5y ago
Naturally. In an Agile environment it's more or less impossible to get it right the first time without seriously forward-thinking architecture, which takes time that could be spent pushing harder towards the deadline. It's a business decision to organize software production this way. Refactoring and ease of software maintenance are quality of life issues for engineers. Not business concerns.

alistairSH 5y ago

Ugh. I haven’t worked with an independent QA team in 15 years or so; testing is the responsibility of the dev team and there are test engineers on each team to facilitate that. Maybe this is a difference of building a product vs contracting? We have to keep what we build running for years; there is no turnover to a client where can declare the system “done”. As for redefining agile, I’ve done no such thing. The agile manifesto calls for working software. It calls for collaboration. Avoiding knowledge sharing amongst team members and throwing software over the fence to a remote test team are both counter to that goal (in my experience).