SDET - missing the point since the 1990s

A term that I still hear occasionally is "SDET", or "Software Development Engineer in Test". It is also known by a few other terms - Developer in Test, Test Automation Engineer and so on. Essentially it is a job role for a developer whose main responsibilities are to write automated tests and frameworks to check software. And it is a truly awful case of missing the point completely. It is a job title that indicates a fundamental systemic problem in an organisation.

First, some history. Back in the Bad Old Days of the 1900s, we used to develop software using a linear waterfall style process, mostly due to a bizarre and tragic misunderstanding of a single academic paper (Royce, 1970). There was a lot of management thinking that modelled software development as a factory production line, and assumed that there were cost reductions from specialisms - someone creates a software design, someone builds that design, and someone tests what has been written. At the end, somehow working software drops out (usually relying on some kind of magical wishful thinking and/or sleight of hand). Long story short, there were whole Departments dedicated to testing. Often they testers were not permitted to even talk to the actual developers building the software - "We can't tell the Developer how their software will be tested! They might write it to PASS THE TESTS!" (Seriously, I am not making this up!).

From this approach, Microsoft invented a new role: "Software Development Engineer in Test" - the mythical "SDET". An SDET was someone who had a keen sense of testing and a love of writing code. (The timeline here is uncertain. The best guess is this was sometime in the late 1990s? Please do comment if you have first hand information). But this role led to a host of issues, not least the SDETs being expected to write all the tests including the unit tests! They were simply seen as a test 'resource' (in the most unpleasant, inhuman application of the term).

Having to hand off code to be tested like this is immensely wasteful. It slows down the feedback to developers often by days or even weeks. Handoffs of any kind have a bad effect, and they need to be minimised. It's not only the handoff that is the issue. Having a separate quality 'gate' that gives the go/no go to software release looks awfully like quality control, by which time it is too late to improve the quality. As Deming put it, "You cannot inspect in quality". (This is also the problem with code reviews, but that's another article...)

The easiest way to remove handoffs and move quality decisions to where they can be actioned quickly is to shift-left. Tackle it earlier in the delivery cycle. We can do this by combining the roles of Software Development Engineer and SDET. A good Developer is more than capable of writing good tests as well as good codel! It's obvious when we think about it. 

Putting it another way, a Software Developer IS a Developer in Test by definition! 

Microsoft eventually realised this and combined the two roles (apparently on the Skype team, which is ironic since Skype is about to be turned off). This resulted in (surprise!) significantly improved productivity. When developers write tests, they speed up the feedback loop significantly, allowing them to react to issues that have been introduced more quickly and efficiently. I would argue that the side effect of thinking about tests and testing up front also has the beneficial side effect of improving design and architectural thinking (which is a reason why Test Driven Development is so effective). 

So next time you see a job advert for SDET, Developer in Test, Automation Engineer or similar, ask yourself why? What organisational dysfunction is causing it to be considered a totally separate role?