Mirfy - Make it Repeatable for Yourself

Mirfy* (pronounced like Murphy) - Make it Repeatable for Yourself - means we should make our workflows repeatable. If you have to run through a workflow a second time, it's time to invest in making it repeatable.

* For the record, I coined this term myself

I follow these steps in making repeatable workflows:

1. Make it repeatable for myself
2. Share the repeatable workflow with a colleague
3. Wrap the workflow with automation

Whenever I have to run through multiple steps in a task at work I try to figure out a way to script all those steps. Most of the time I'm successful in doing so. It also happens that I may never run that workflow ever again but it's very rare. Most times I'm required to revisit the task to either improve it or run it as-is. I have seldom come across a one-off task that truly was one-off. That is when it pays for me to have scripted it the first time.

A repeatable task can also serve as documentation of assumptions, design, trade-offs, and final execution. It becomes an historical artifact. If it's put under version control it starts to gather history.

This is where it becomes easier to share a repeatable workflow with your peers. It's not always easy but it does expose the underlying weaknesses of assumptions made in the solution or understanding of the problem. This is a great opportunity to fix these flaws. Now the same artifact can be executed by two or more people. It not only reduces the bus factor but encourages collaboration. It's also the next step in wrapping this artifact in automation.

I define automation as zero touch (or as close as practical) execution of a workflow. If I have to intervene at any stage during the course of a workflow, it is not automated. It is repeatable, for sure, but it's not automated. In other words, automation to me is binary: either it's (fully) automated or it's not automated. We should have the flexibility to provide inputs to an automated workflow but after that the only interaction we have with it must be when the final results are emitted at the end.

Given this context, wrapping a repeatable workflow in automation gives it the longevity it deserves. It also unshackles a single person or team from the burden of carrying around the organizational knowledge. By peeling away the layers of automation, shared repeatable workflow, and finally, the original repeatable workflow, any person new to the workflow can understand each layer. There's no longer a massive need to have detached documentation about the workflow. The layers of repetability and automation carry their own documentation with them.

Is this too abstract in theory? Let's try to explore this idea with an example.

I write this blog using Nikola static site generator. Primarily, I use two commands: nikola new_post -f markdown and nikola build. I also use git for version control. I then use Ansible to push the output of the build process to a webserver. All posts go through the workflow of creating a new post, adding content, adding it to git's control, building the site, and pushing it to the webserver. This is an oft-repeated task. I have made it repeatable by capturing the commands I run all the time into a Makefile. Now the task of writing a new blog post and publishing it has become a repeatable workflow. That is step 1.

If there was another contributor who wanted to share their own content through this website, I could push the git repository to a shared service and give them commit access. They could use the same make tasks to add their own content. My repeatable workflow is now shared between two or more people. That makes it step 2.

By step 2 it's clear that someone still needs to push the output of nikola build to the webserver after each build. Since people are publishing content independently, some coordination is called for. We don't want folks to be stepping on each other's toes as we work. This is where automation comes in. We (people) run the parts of the workflow that add content. Then we push our git commits to the shared service. Some automation then builds each commit and publishes it. Automation runs through the same workflow steps I was running in step 1 but now it is serving step 2 needs. This automation is step 3.

From this example I hope I made it clearer what mirfy really means. Let me also put it in other words: make your tasks repeatable for your own sake first. Then layer more repeatability so others can benefit individually. Finally, when it makes sense, add a third layer of repeatability (automation) that runs most of the workflow to benefit the entire group together. This ties into my other idea of DevScale: start small, focusing on an individual, then scale it to more people. That, in short, describes mirfy really well.