Not the author, but I'm a VP of Eng, and one of my sub-orgs is QA. Here's my take...
Aside from writing end-to-end test automation, the best SDETs add value in many other ways. They triage bugs, use their deep product understanding (frequently the best on the team) to refine requirements and build test plans, coordinate bug-bashes and large scale releases, measure and report on quality metrics, and much more. All of this takes considerable load off other members of the team (SWEs, PMs, EMs, etc), allows the whole group to ship with much higher confidence, and increases the number of defects caught before making it to production.
If you have an organization where end-to-end tests are easy to write and very quick to execute, then I think the need for QA folks is greatly reduced. In my experience, once there's enough complexity and scale to a product, it's basically impossible to have a rapid TDD loop with enough end-to-end coverage that allows devs to ship features with perfect confidence. Combine that with all the other "hats" QA folks wear, and I think it's is a role that pays dividends in product quality and the efficiency of others across the org.
I think it’s a good takeaway for something that’s sold once on an app store. If it’s junk, the rankings will tank it, and it may never recover from that. There are a few instances of games that have turned things around after the initial launch, like “No Man’s Sky”, but that’s quite rare.
Take Half-Life as an example. The team realized it wasn’t great after multiple years of development, and ended up essentially rebuilding it over the course of another year or two. To quote Gabe Newell, “Late is just for a little while. Suck is forever.”
Your take is spot on for SaaS apps and enterprise software that’s subscription based: ship early, ship often, and iterate fast.
I recently learned about The Villages, FL, which is a sprawling retirement community, and was the fastest growing metro area in the US over the past decade [0]. This feels like the perfect bike for an aging demographic living in that sort of community. This sort of e-bike will be less intimidating to use for older people, and ultimately it feels like a good move for the company. It's hard to argue with getting more people outdoors and active on bicycles.
Unless I'm misunderstanding something, I see a possible issue with the experiment setup.
> The start-of-input was measured by pressing two keys at once -- one key on the keyboard and a button that was also connected to the logic analyzer.
In order to get an accurate measurement, wouldn't you need to directly connect the analyzer to circuitry on the underside of a specific key, as well as the USB output, and measure the diff? The article addresses this by mentioning it's only possible to get average latencies with their setup, but I wonder if this is why the keyboard with the shortest measured latency is also one with an extremely low travel distance.
Aside from writing end-to-end test automation, the best SDETs add value in many other ways. They triage bugs, use their deep product understanding (frequently the best on the team) to refine requirements and build test plans, coordinate bug-bashes and large scale releases, measure and report on quality metrics, and much more. All of this takes considerable load off other members of the team (SWEs, PMs, EMs, etc), allows the whole group to ship with much higher confidence, and increases the number of defects caught before making it to production.
If you have an organization where end-to-end tests are easy to write and very quick to execute, then I think the need for QA folks is greatly reduced. In my experience, once there's enough complexity and scale to a product, it's basically impossible to have a rapid TDD loop with enough end-to-end coverage that allows devs to ship features with perfect confidence. Combine that with all the other "hats" QA folks wear, and I think it's is a role that pays dividends in product quality and the efficiency of others across the org.