Suppose the following is all true:

  1. There’s an ice cube maker and a water dispenser in your freezer
  2. The plumbing is all done, so water is already routed to your freezer
  3. The ice cube maker in your freezer wasn’t set up completely by the guys at the factory
  4. You’re a freezer engineer, so you know how to tweak/fix the ice cube maker to your heart’s desire

Knowing all this, how do you make ice cubes?

Do you take out an ice cube tray, go to your freezer, press the water button to fill the tray, put the tray inside your freezer, wait for the water to freeze, pull out the tray and twist it to break the ice apart, then pour the ice cubes into your freezer’s ice tub?

Or, do you use your skills as a freezer engineer to fix it so that your freezer makes the ice you want? Then, when you want ice, all you have to do is take your glass over to the freezer and press the ice button.

If you weren’t confident in your abilities as a freezer engineer, I could see how you’d want to just stick to using an ice tray, that’s really easy and anyone can do it.

The thing is, you claim to be a freezer engineer, so why do you keep suggesting we use ice cube trays?

For context, I wrote this analogy in an attempt to explain the difference between two programming approaches.

  • One where a task is entirely done via one API call to a self-contained app: it sends an email to folks who have not yet done X.
  • The other is where (via API call) you export all the data for folks who have not done X, then do the work of sending an email in an external app.

Both have their merit, but in my particular scenario I’m looking to keep the logic, code, etc within the standalone app that’s being called via API.