4 ms·
It doesn't need to be as valuable to still be net positive though, because now it doesn't take human time, just computer time. Imagine for an ML product, makin
by snovv_crash 4y ago
It doesn't need to be as valuable to still be net positive though, because now it doesn't take human time, just computer time.
Imagine for an ML product, making an accuracy report. If it's slow and required lots of human time, you might do it once a quarter for releases to important customers. If it's cheap and quick then you can run it on every CI run to check for regressions before merging code. Sure, you run it maybe 1000x more and don't get 1000x the value.
But, critically, the value is not the cost savings of not having to run it manually per quarter, the value is the more stable product and avoiding spending time bisecting a quarter of engineering work to figure out where bugs were introduced. And this was enabled by automating.
- majormajor 4y agoSure, if the cost of automating here is < the current cost of rework and investigation, you win. And dev time is expensive, so that sort of thing is usually an easy call. Yeah, it doesn't need to continue to increase in value linearly with repeated runs, it's the summed value that matters. The "cost" is fuzzy too, often - e.g. time and budget spent on reliability-focused engineers or active troubleshooting rarely drops to 0 if you don't automate anything. It might just make it more expensive to react to incidents! Maybe turn it away from a "gate" question - "should this thing be automated" - and into a prioritization one - "we could automate so many things, which ones should we do first?"