[Silhouette]

But if you're working on software that actually matters, you're supposed to have some friction between the people building it and the people testing it. This is otherwise known by terms such as "independent testing" and "lack of bias".

Moving fast and breaking stuff is OK if you're building a web service that doesn't really matter. If Facebook falls over, the productivity at a significant number of businesses probably goes up.

On the other hand, if yesterday's OS security patch stops everyone's PC from booting this morning, or if a new version of your e-mail server has a glitch that means half your company can't log in to read their mail or even that important messages from customers are actually being lost, that probably comes with a cost measured in large numbers of dollars per minute at a medium-sized business, or if you prefer, in careers per hour within the IT group.

[bztzt]

there is a separate, smaller "quality" team with a separate reporting hierarchy that is supposed to address this - that's where the reference to data scientists, etc. in the article comes from.

basically the idea is to split the SDET role into two - SE testing (closer to the code than SDETs used to be) and "quality" (further from the code than SDETs used to be). SDET testing, though not directly driven by the code structure, tended to be at a pretty low level driven by a detailed functional spec.

[kaeawc]

Software engineers should be able to test their own code. The faster they get feedback on their code and its impact to users, the better they understand the various cases and can strive for better quality. Having a separate QA team has a fairly long feedback cycle.

Ideally you'd get both engineers writing tests for their code as well QA teams for products.

[Silhouette]

Software engineers should be able to test their own code.

Indeed, but there is also a good reason that professional editors have new writing proofread or even technically reviewed by people other than the original author.

Maybe there's some subtlety that I'm not picking up here about Microsoft's previous set-up and/or the model they've been moving to under Nadella's leadership. We seem to have some past and present Microsoft developers around these parts, so perhaps their comments will clarify this. But as reported, this looks to me like a retrograde step, an attempt to be more agile and fast-moving rather than something likely to improve the quality of the finished product.