What Oatmeal Taught me about Software

Photo by Andrea Tummons on Unsplash

Recently I had a life changing moment. I was having lunch with a friend and he told me that he makes oatmeal in the microwave. Not those instant packets where you essentially just add hot water, but actual oatmeal.

I know, this does not seem like it should be a pivotal moment in my life.

I am sure lots of people make oatmeal in the microwave. The things is though, I love oatmeal, but I don't eat it because I am far too easily distracted to watch oatmeal long enough to cook it on the stove. I've tried doing it in my Instant Pot, but you can't really just make a 1/4 cup and then there's all this cold cooked oatmeal that no sane person wants to eat. So essentially, I had given up on oatmeal.

Well, making it in the microwave is a game changer. I measure the stuff out, put it in the microwave, an 17 minutes later there is perfectly cooked oatmeal. If I forget and come back 40 minutes (or 2 hours) later, it isn't burnt to the pot, nothing is on fire, and I haven't ruined yet another pot. I eat the oatmeal, I stick the bowl in the dishwasher and I'm done.

As much as I love oatmeal, the actual oatmeal isn't what changed my life. What changed my life was realizing that despite having had a microwave for most of my adult life; despite using my microwave at least once a day for that entire time; I had never thought of it as a solution to my oatmeal problem. What changed my life was the absolute undeniable slap in the face that I am way too complacent in my assumptions about even the most banal of things. I need to be far more diligent in actively challenging my own assumptions.

And when I got to thinking about this my mind, as it does, turned to software. And once it did, I was able to really fundamentally question how we build software, and how our assumptions are holding us back from growth. What I see is that from inception to delivery, our foundational premise of what software is, leads us astray.

We start by assuming that the software is going to allow a user to do something whether that be buy a cell phone, look up information, or generate a set of monthly invoices, we start with the assumption that there is a process that we are automating. This fundamental assumption inhibits us because it means a) that we build a lot of software that is based on bad processes, old assumptions, and restrictions that no longer exist, but more importantly b) it assumes that we know what are users are going to need to do in the future, whether that future be 10 years from now or tomorrow.

What if we stopped assuming that we knew what users needed to do and built capabilities. What is we built capabilities that were aware of regulations and business rules but were really just the base Lego blocks of a solution, and then allowed those blocks to be assembled to meet a users request at (or near) run-time. If we did this we could stop this endless cycle of rebuilding software because something had changed. Yes, there are situations where people really do ask for the same thing over and over and rethinking the process every time is not efficient, but what if we thought of the process as something to be cached, not something to be coded?

This isn't a new idea. We have lots of tools that allow a system to enter and maintain a certain state (Ansible pops to mind). What if we allowed the user to tell us the state they wanted to achieve -- I want customer a to be mailed an iPhone, and I need all of the intermediate steps (think billing, packaging, sending a friendly welcome email, shipping, inventory control) to happen along the way; -- I want to know how many blue iPhones were sold last month during the "am I blue" sales campaign; and the system itself assembled the information and processes to achieve this goal.

Why bother you ask? I know the steps to sell and ship a customer an iPhone, I have software that does it. What you don't know is what are the steps going to be next week, what is the user going to really need next week, what are we going to do if something unexpected is different?

Now, this is the same conversation as the automation discussion about imperative rather than declarative code. By making user software processes imperative, you have to guess in advance what all of the edge cases; external changes; process changes; and unknown unknows are before you start. And when you get it wrong, or you miss something, you have to open the software and make a change, and test that change, and deploy that change. In addition we have to change all the interconnections between the pieces because they are also imperative. In the end it is a fundamentally fragile system and it will be until we build software that is adaptable.

If we discard the Architectural decisions that we made in the past, that we have come to see as unchangeable, and really look at the tools we have in our tool box today. We can, as technology teams, provide something different, that is better. We just need to think differently.