Is It Worth It?
11 points by WilhelmVonWeiner
11 points by WilhelmVonWeiner
The post does not take into account that the time needed to fix something is not known in advance. The question should be asked also while being busy fixing the issue. "I've spent an hour trying to fix this test that costs us four hours over the lifetime of the system, but was estimated to take one hour to fix. I have three hours left to break even. If I stop now, it's a loss. If I continue, the same logic holds: I have four hours to fix the issue. However, I now estimate that the fix will take five more hours."
But there's an XKCD for that: https://www.explainxkcd.com/wiki/index.php/1319:_Automation
Forget the raw time, even per person. Does automating a task sufficiently produce extra gains in other areas? Will you or others want to perform the task, or a related task, more as a result of your automation?
Tasks live in a system. It's easy as engineers to focus on one task and miss the broader picture wherein that task mirrors other work that, when automated, will be very useful.
One classic example is a report that an org ran monthly. The report was fully automated, contrary to the suggestion of XKCD 1205. Result? The report was run daily and became a touchstone for all management decisions.
In my personal life, I automated the ability to assign colors to an OpenSCAD STL and have those colors map to filament extruders in Orcaslicer. A task I used to perform... never, but the capability means I'm looking at multi-material prints much more often. The time savings BEFORE I wrote the automation would not justify it. The time savings AFTER the automation exists? Totally.
In a previous position, I automated producing documents that used to take about 5 minutes to do, down to the time it takes to type the command (ultimately I redid the core work and open sourced it) XKCD 1205 would have had me stop after a few days, it took me weeks to get it right. Then suddenly the position required a lot of documents done in short order, and I went from the "5 days" box on XKCD 1205 to the "9 months" box. Increased pressure on the job went from "can't do it boss sorry" to "totally got it boss, we're good." That style of automation spread too, and shrunk other tasks.
With automation, a small team or lone hobbyist, can wrangle massive machinery and keep up with extreme demands. Barring comparative advantage (something else that's more obviously useful), isn't further automation always worth the time?
Your examples are shifting the goal post a little bit. If building automation that was deemed "not worth it" suddenly became worth it now that you're running it daily instead of once a month, great! But that seems like something that could have been decided upfront with updated requirements. What if you overran the time budget by double or triple and you still only run the report once a month?
Basically, we can't always predict that time invested into the automation will always be worth it, especially if we don't understand the problem well enough. Or, how the result will be used. Taking the time to figure that out is arguably worth it. But that doesn't mean the resulting automation is always worth it.
In my experience, I've had opportunities and even tasks assigned to me to automate something that, when actually looking into it, took 1 or 2 minutes total of human time once a month and that frequency wouldn't change. Spending hours to figure out how to build automation would have been a waste.
As for «further» + «always», I have been in situations where further polishing exceptional cases — while lacking any plan for decreasing the much larger currently-largest part of manually processed cases — was deemed not worth it.
(It was about figuring out the 8-digit page code, typically shared with either the previous or the next page, normally auto-obtained from a 2D code, but sometimes from the printed number and sometimes there was handwriting and sometimes there was indeed no code. «Is it a numbered page or a draft unnumbered page» for pages without any code and with some handwriting was drowning out «is it same code as next or previous» for misscanned pages.)
I have the XKCD comic this references bookmarked and refer to it often! I've used it recently to make a case for not automating something we do internally once a month. The investigation of how to automate it would have taken way longer than the "allowed" time, so we dropped it.
But, I can appreciate the argument here as well: that when we multiply out the efforts saved across multiple people in a corporate setting, we actually have more time to automate (or fix) something than we realize.
I think the same concept can be applied to our core codebases as well, whether our customers are internal or external. I recall Joran from TigerBeetle making a similar argument for quality and performance. Yes, quality takes longer in many (most?) cases, but the total human-hours our software will impact as it grows in adoption is staggering. So these investments are worth it.
I think the overall principle is just: take a few minutes and do the math! Its ok to automate (or fix) or decide not to, but basic math gives you more confidence in the decision.
The real comparison one does, is how frustrating even if relatively quick the task to automate is, and how much one cares about progress on the thing which will suffer opportunity cost of developing the automation.
(Well, unless one can sneak most of the work into an open-source project the company already contributes to, then there are extra variables…)