Code Review as a Service

Re:Code Review as a Service by alistairSH on Monday December 20, 2021 @09:18AM (#29625176)

His logic would apply to tests of all sorts. As long as the dev says the feature is done, that’s the end. And he’s wrong. As teams (or companies, or whatever unit) we get to decide our definition of “Done”. I suggest that definition include appropriate testing. And appropriate code review, which serves two purposes… catching defects and knowledge sharing.

[ Parent | on HN ]

Re:Code Review as a Service by vinceguidry on Monday December 20, 2021 @09:45AM (#29625424)

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.

[ Parent | on HN ]

Re:Code Review as a Service by alistairSH on Monday December 20, 2021 @03:49PM (#29630108)

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

[ Parent | on HN ]

Re:Code Review as a Service by Pxtl on Monday December 20, 2021 @10:28AM (#29625954)

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.

[ Parent | on HN ]

Re:Code Review as a Service by vinceguidry on Monday December 20, 2021 @10:39AM (#29626086)

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.

[ Parent | on HN ]