They lost hundreds of thousands of dollars on an issue that was in production for several days. On the one and only feature generating revenue: showing ads.
No unit testing, no integration testing (as was admitted) and no production sanity test at all. I guess the accountant was asleep at the wheel as well.
> But how strong and reliable are your test environments to ensure that this all works correctly? How much effort, time, and money does it take to maintain full testing solutions?
Seriously? The entire company revenue depends on counting ad views and you don't have resources to make sure you're counting right? Oh, c'mon!
Strong typing has its place, but this was a bad argument in favor of it...
You’re assuming this was the only location they showed ads.
It could have been one of the many components displaying ads. And this specific component might have accounted for a small percentage of those ads.
And presumably this wasn’t the only feature deployed so any noticeable change in revenues could have been attributed to many other things before a typo in the ID would have been discovered.
Agreed, and as someone who likes Typescript and typed languages in general, I've noticed many of the loudest "OMG HOW can you develop without Typescript" also tend to be people who don't write tests.
It's like the types are one giant unit test for them.
Yes, this was my takeaway as well: no KPI relation ship tests whatsoever. This should have never passed testing. But that doesn't mean TS doesn't have advantages, just that this particular error could have - and should have - been caught by other means as well before hitting production.
So both of these would have been good, none of them was clearly bad. Notice that you don't necessarily have to choose between these two.
No unit testing, no integration testing (as was admitted) and no production sanity test at all. I guess the accountant was asleep at the wheel as well.
You have bigger issues than strong types.