Nerd For Tech
Published in

Nerd For Tech

The Paradigm Shifts with Different Dev:Test Ratios

How things changed going from 1:1, to 10:1, to 100:1

Phase I — The 1:1 dev:test ratio days

When I started at Microsoft in 1997, we had a 1:1 dev:test ratio, meaning there was as many testers as developers. I think one of the motivators was the static, waterfall nature of shrink-wrap software. Back then, we were certifying builds of things like Microsoft Office, or Microsoft Windows. The product was released roughly every three years. And when it was released, it meant burning 50 million copies of the CD, and physically shipping them to stores. The Group Manager had all the testers sign their approval of the final build in an actual piece of paper that she then framed and hung. I was responsible for copying the final official bits of my DLL onto the Microsoft Office shared drive that was going to be used to burn the master CDs. If you had a bug, that bug would live forever, burned onto that CD for eternity (or until that person used that CD as a coaster for their drink). It wasn’t until years later than Microsoft added the ability for software to ping the internet for updates and automatically install them. In 1997 some customers would maybe download patches manually, if we were lucky. So the stakes were high, and Microsoft mitigated that with a 1:1 dev:test ratio.

The 1:1 dev:test ratio, in the pulley analogy (source).

Phase II — The 10:1 dev:test ratio days

When I started at Amazon in 2009, we had a 10:1 dev:test ratio. This was a significant paradigm shift for me. The main difference is we were working on web services and not shrink-wrapped software. You could have good telemetry in your web service. Those real-time metrics (CPU usage, JVM metrics, latency of transactions, error rate, etc) were connected to alarms which were connected to pagers, and there was always somebody oncall. If a metric exceeded the threshold, you would get paged, drop whatever you were doing, rollback the environment (these rollbacks could even happen automatically based on alarms), investigate, fix the bug, push the fix, and your millions of customers would immediately get it. It was an entirely different world from shrink-wrapped software where there were millions of copies of your software in the wild burned to CDs or DVDs. With web services, there was a single authoritative copy of your software, in the servers you owned. So knowing when something was broken it, and addressing the problem, were significantly easier than in the old world. Not particularly good for life-work balance, but great telemetry and a pager could make up for a multitude of deficiencies in testing.

The 10:1 dev:test ratio, in the pulley analogy (source).

Phase III — The 100:1 dev:test ratio days

There was a small change brewing at these big companies. Microsoft removed the SDET title altogether circa 2015. Google removed the SETI title as well (in reality SETIs didn’t quite go away, but they became developers more officially, in the discipline of Engineering Productivity, or “EngProd”). Amazon meanwhile did not drop its SDET role but slowed down the hiring of SDETs. In 2009, Amazon had 300 SDETs and 3,000 SDEs; in 2020, Amazon had 600 SDETs and 50,000 SDEs, effectively changing the dev:test ratio from 10:1 to 100:1 over the course of a decade.

The 100:1 dev:test ratio, in the pulley analogy (source).

Phase IV — ???

I don’t know what the future holds. I continue to ask myself on a regular basis: am I a dinosaur? Do I need to evolve?



NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Carlos Arguelles

Hi! I'm a Senior Staff Engineer at Google. Prior to Google, I was a Principal Engineer at Amazon for 11 yrs, and before that, I spent 11 years at Microsoft.