To automate, or not to automate?
By Marty Bacik
My internal dilemmas when deciding, and some heuristics to use
As engineers, we like boolean logic. We like yes or no answers. We like right answers. So, when coming across problems that do not have right answers, it invokes a different pattern of thinking that we don’t use every day. And for me at least, it can be a little daunting. One of these such problems is deciding whether you should spend the time engineering a task, or just do it manually. I think as engineers we often default to the technical solution, even if it means spending way more time putting together the pieces to automate something vs just copy pasting something 50 times.
I came to my manager with this exact dilemma the other week. We wanted to adjust our prices on several of our products, and within the App Store Connect portal you need to adjust each country separately. So, between say 5 products, each with 1 intro offer and 2 promotional offers and 50 different countries (ideally you’d set 175, all that Apple has available), that is 1,000 different price points that need to be adjusted.
Off the bat, I had a feeling in my gut that this was something worth spending the time on automating. I mean pressing the price, entering the new one, and pressing save a thousand times?? So, even though my internal alarm bells were going off, I couldn’t really be sure. I mean, I had never used Apple’s APIs to set prices before. Beyond this, I needed to create a Python script to translate the excel sheet of prices and countries from my PM into a format that the API automation script would understand.
I made the decision to bite the bullet and create a script to call the API for each country, price, and product, and I can pretty confidently say now that it was the right choice. Although, part of the challenge with these decisions is you’ll never actually know if you picked the right thing (unless you go back and do it again manually or engineer it). You lack a feedback system for the next time. In order to make this decision slightly easier, I am going to share times I feel an engineered solution has been worth it, when it was worth it to just do manually, and some heuristics that resulted from these times.
When it has been worth it
The first example I’ll share is the same from above. Even though I didn’t know prices would take, it undoubtedly took less time than typing 1,000+ prices. Beyond the time piece, it is likely we will change prices again in some fashion, and I now have the script to reuse.
The second example isn’t exactly automation, but it involved me adding a button to our internal admin tool to set a value for a user in our database. Previously, I would receive a request, then enter the value manually in the DB. This took me all of maybe 2 minutes. This decision was not as clear cut as the above because of how quickly I could add this value. But, over the course of several requests, the time commitment slowly added up, plus I was a single point of failure for this process. By spending the time to add this to the admin portal, not only did I save myself time, but I made myself redundant to a degree by allowing anyone at the company to perform this action.
When engineering wasn’t worth it
To give a counterexample of when I felt that going the manual route was better is actually adjacent to the Apple price example - modifying prices for Android. You would think that I would make the same decision for the same project on a different store interface, but the differences between the interfaces actually made me choose a different route. Within the Google Play store, you are able to create a discount which automatically sets the value based on the base price of the product. For Apple, you need to go in and set all these manually. So even though you may want to offer your user a 30%, if you don’t adjust the price in the currency correctly, they may get a wildly different discount.
This seemingly simple difference reduced the amount of changes necessary from over 1,000 to just 350. And yes, this still seems like a lot of manual change, but learning the Google APIs and creating an entirely new script didn’t seem worth it to me, so I made a judgement call.
Heuristics to Use
From the instances above here are some rules to use when deciding whether to create an engineered solution to a task or just to do it manually.
- Will this task need to happen again? - If it is likely that a task is going to be performed multiple times, it becomes more likely that an engineered solution will make the most sense in the long term, even if it takes longer the first time.
- Is redundancy important? - It may be quick for you to ‘just get it done’, but what happens if you are on vacation? Or leave the company? If there needs to be a layer of redundancy and right now you are the only one who knows how to manually perform a task, it may be worth spending time on creating a more automated and general purpose solution.
- Will the engineered solution require maintenance? - I’ve seen engineered solutions several times here at Calm which died when the person left the company because no one knew how to maintain the tech that they made. We’ve shut down entire services for this reason. Be careful about creating something that only you know how to maintain (I’m looking at you, golang service to ingest Android webhooks) when you are making a decision to manually finish something or engineer it.
Use your best judgement when making a decision on whether to engineer a solution or use brute force. You won’t always make the right call, and that’s ok! Even asking yourself these questions in the first place helps to make you a better engineer.
