what1fool.info

1 do it manually before you automate

(this article is an unfinished draft)

It's sometimes recommended to carry out an operations activity manually for some time before attempting to automate – as I understand this recommendation is meant to help understand the details of an operational task without implementing automation that turns out to be badly-suited to the task.

This brings up a couple of questions for me:

  • who is making the recommendation?
  • what do we really mean by the terms "manual" and "automated"?

Per my memory, I first encountered the "manual then automate" recommendation when I was working at a SAAS firm that had operated as a small business for something like 5 or 7 years before deciding to accept venture funding in hopes of acheiving larger success.

What that meant for me at the time: There were a small number of long-tenure technical staff, plus a lot of newly hired, relatively less experienced staff. Including me. I was a QA specialist whose self-taught Python skills had only recently gotten good enough to be marketable.

One of the new teams introduced to this business was a dedicated operations team of 3 people. I quickly found out that this team was a lot more openly supportive of my professional growth compared with the development team, at least as I perceived it. I decided that Ops would be a good next place for me to go since the QA team did not get the infrastructure and policies that were needed for us to do a good job, and we got no respect either.

I started trying to imitate the practices of the Ops team, including the reading of EverythingSysadmin by Tom Limoncelli which includes a list of "look-fors" that can serve as a yardstick when measuring the adoption of DevOps practices.†

I am only going to discuss "Milestone 2" since this is the point in Limoncelli's post that forces the reader to decide whether they will:

  1. do stuff manually, document it, then eventually automate it, or
  2. write the automation immediately in hopes of saving time (and with the implication that the person writing the automation understands the problem completely)

† I am not going to address the definition of DevOps here, since I don't know. But I knew that operations of this company displayed problems that DevOps claims to address. I also thought that pursuing a loosely-defined DevOps transformation would be a way to mitigate those problems, based on writing and advocacy by Limoncelli and others. My working definition of DevOps was basically "that which is advocated by these DevOps authors"

Author: Coffee Crayon

Created: 2019-08-13 Tue 10:40

Validate