December 17, 2019

Day 17 - Automation in Everyday Life: It’s not always about velocity

By: Michael Stahnke (@stahnma)
Edited by: Joshua Zimmerman (@TheJewberwocky)

We automate technology for three main reasons:

  • Speed
  • Consistency
  • To get onto things that matter – solving new problems

In nearly all cases, people think automation is about speed. Speed is a benefit, but in most situations, speed is a very distant second place to the consistency you can arrive at when automation practices are in play. When you automate a bad process, you just get bad output, but faster. However, you will get the same type of bad output each time, meaning it is easier to make improvements and see results. Consistency matters.

I think in terms of automation. I think about repeatable process, speed of delivery, and how I can do more of the things I wish I was doing vs the things I have to do. Sometimes, I like to tinker with technology for automation. Sometimes, I have a plan.

Automation mindset

Recently, I had a friend point out that I live automation – beyond my career. This is embodied in my desire to cook meals. You see, I have a smoker and I like smoke meats and other foods. For those a little less familiar with this style of cooking, it is usually lower temperatures (~225ºF/ 107 ºC) for a rather long time (6–14 hours of cook time). The results are tasty entrees and meals.

The important parts for me were to get good results and to have minimal hands-on time with the cooking. This is so I can cook on a work day, or on a day I want to spend out and about with my family. This desire for minimal touch and consistency got me thinking about the three principles of automation I had been using as a mental framework for years.

Automated smoked meat delivery is not about speed. In fact, speed is the least important part of the equation. I am interested in consistency, quality, and how much manual intervention is required by me to get an awesome meal.

The process

At its core this food delivery process has the following steps.

  1. Decide on what you want to make
  2. Gather materials
  3. Prepare food for cooking
  4. Prepare smoker for cooking
  5. Cook Meal
  6. Continuously validate meal is cooking properly
  7. Remove meal
  8. Eat
  9. Clean smoker.

During the process, I am most concerned about step 6. If the smoking lasts 6 to 14 hours, how do I know the cook is going ok? How much time do I have to course correct? How much supervision will this require?

Equipment

Enter my Green Mountain Grills (GMG) Daniel Boone. This is a Pellet Grill smoker that burns small wood pellets as fuel. The nice thing about this class of grill is that you can have a large hopper of fuel, set a temperature and the grill moderates the fuel and temperature using an auger for the fuel and fans for the flames. This allows me to set a desired state (temperature) and the grill will be the engine enforcing that. It also has WiFi, so I can adjust the temperatures via my mobile device.

Inputs

Like any automation project, this one starts with requirements and learning about market trends. Normally, I start by asking my spouse what she is in the mood for, or if cooking for a larger group gauging interest in different dishes.

I break down the cook into smaller segments and inputs. This inputs are things like, desired cooking temperature, desired food completion temperature, and type of wood to use for the cook. These are implementation details, much like selecting a programming language or database to use in software delivery. I also make an estimate at this phase, for the duration of the cook. Much like software engineering, my estimates are often off by more than a little, but do improve over time.

After preparation, I begin the process of continuous validation of the food payload and adjust cooking parameters until the payload passes the validation suite (e.g. internal temperature and time frame constraints).

Begin the cooking

The food is on the grill. The grill is smoking. I am now continuously validating the state of the grill and the food. The grill comes with some instrumentation built in. It can display the current temperature of the grill and the temperature of the food where I have placed a food probe.

After a few cooks, I realized that something was not behaving as expected with this system. Even with my mobile device monitoring and sometimes adjusting the grill, the temperature of the food was not matching my expected duration of cook properly. I decided to opt for a way to monitor the system from a secondary source. Perhaps observing the system completely within the system was the problem.

Instrumentation

While my food wasn’t turning out horribly, it wasn’t quite right. Knowing that more ability to gain insight into the cook process would help, I bought an external temperature probe set where I placed on the grill and one in the food I’m cooking (so now I have two data points for food and two for ambient grill temp). This told me that the original grill temperture readings were often reporting much lower than they actually were, meaning I was cooking too fast. This also meant that I needed to adjust temperature a little more often than I had originally hoped for.

In the pipeline model, temperature being out of bounds is a failure. A failure means I need to take action to recover. Sometimes that can be simply to lower desired oven temperature, sometimes it means basting the food, opening the grill lid, or something else.

Continuous Improvement

Since most of these interventions required layer 1 connectivity to the grill (e.g. I had to touch the grill), I decided to optimize for the methods that explicitly did not require physical contact. This way, I could work my setup while I was working throughout the day. I had learned that the WiFi connections for the smoker used uPNP for discovery and communication. I whipped up a little CLI to send commands to the smoker and get output back. After a bit of fiddling around, I searched Github and found that somebody had written something more robust than I had. A web application existed and was easily deployable via a container. Cool. Now I could monitor the grill in my browser and didn’t need my phone out. This was helpful since I work from home and have a browser up nearly always.

Validation

Now that I can make easier adjustments to the meat delivery system, and had added monitoring and instrumentation, there were still a few other cases to handle. For example, if our delivery pipeline is a series of tests where each test is a sample of the current temp as compared to the desired temperature. The combination of all these tests into a single suite is the delivery pipeline, and you run it until they pass (or you fail completely, but that’s pretty rare).

While the meal is cooking you can get into all the traditional conditions of a validation pipeline. You have

  • Success – everything is operating as expected. (E.g. tests are running and passing)
  • Failure – Temp is not where you want it. Food is not cooking as expected. Perhaps wind is causing fuel consumption to be much higher than your capacity planning model showed.
  • Error – unable to get the right data. Perhaps out of fuel? Power outage? Battery is dead on temp probe? Dog has stolen the food?

The pipeline concludes when each test passes. Normally the grill temperature samples work fine and the food temperature is what we wait on. Once the food temperature is optimal the pipeline can be complete. It’s time to remove the payload.

Deployment

After a rest period, we carve, stir, mix, pull, or unwrap the food, depending on the type. After the smoker has had time to cool down (usually while we’re eating), it can be cleaned. This is much like workspace cleaning in any continuous integration platform. You don’t want your next set of tests (cook) to be tainted by previous artifacts…like to those bits of food that stick onto the grill tray.

Retry

My automation thought process started with the desire for a slow-cooked meal, and then went through basically all phases of a Software Delivery Lifecycle model with automation as the method to drive consistency in output. In short, automation provides tasty solutions to my problems.

In the end, I use my smoker a few times a month. I enjoy it, and I enjoy tinkering with the setup almost as much as the food itself. I also love that I can leave it alone for 8+ hours while playing with my son or doing other things and still be pretty confident that my evening meal will be awesome, and after all, what’s the point of automation if I can’t be confident in it?

If you want to see pictures of my meal creations (and all my other shenanigans online), you can follow me on twitter at @stahnma.

No comments :