Tag: DevOps

Some of the early science fiction books I read were by Robert Heinlein, often including rocket ships and space travel. These days I’m uninterested in actually going to space, but I am excited by the prospect of the efforts being made to send others. It’s an exciting time to be interested in travel off of this planet.

One of the headline makers is SpaceX, which has had quite a bit of success launching reusable rockets carrying all sorts of cargo. My son was very interested in their work as an 18 year old, and I still remember taking him to Cape Canaveral and watching the first first rocket launch and land at the facility. An exciting time for us.

SpaceX has adopted a DevOps attitude towards their physical rockets, adapting and iterating quickly to improve their designs. The pace of progress is quite interesting, analogous to how some companies have changed their software development lifecycle practices, becoming quite adept at building and improving applications in a rapid fashion. Alex Yates draws some parallels, and includes lots of fascinating rocket information, in this post on the Octopus Deploy blog.

One of the big challenges I find with changing software development is that we struggle to let go of old practices. Even as we look to iterate, often we are unable to accept risk, and we often want to stick with the “always done it this way” for some things. While we might accept some changes, we don’t accept others, and may even cancel out the benefits of automation improvements with a lack of willingness to adapt our culture.

I do hope that other companies challenge SpaceX, and learn from them. Ultimately we do better with a competitor that forces them to continue to improve and not rest on past success. The same is necessary for software development teams to continually improve. If your organization is stuck in a rut with software development, request (or push) for a team to try something new. To adopt and grow with DevOps. Make them prove they can build, deploy, and operate software in a better way. Then challenge other teams to try and adopt their ideas, and then improve upon them over time.

Steve Jones

In most of my jobs, I’ve been given tasks to accomplish, often without a lot of my own input. Someone triages work, or develops a project plan and then assigns me things to do. Often these are fairly narrow pieces of work, but with some latitude on how I might actually complete the task.

Over the years, I’ve been asked to do things that weren’t a part of my job. At one small company, I spent an afternoon making Ethernet patch cables because we needed them, I knew how, and my boss said it was a good break for the two of us. At another job, I was asked to help go through the separation process when employees left, zipping up files, archiving mailboxes, etc.

At the same time, I recognize that for my salary, neither of those were a good use of my time. At least not from an ROI perspective for the company. Those are simpler, low value tasks, and for someone that is paid above a beginning level, these were expensive resource costs.

As we look to improve how software is built *and* managed, we want to take away low value tasks that don’t require human intervention. We want to use computers to do as much of those tasks as we can. That’s a lot of what DevOps tries to get us to adopt as part of our daily work.

However, this can even include tasks where we might think a human is needed. I heard someone say recently that they shouldn’t be spending time with auditors walking through logs or looking up process documentation. That stuff ought to be produced and available automatically or in a a self-service way.

Improving the efficiency of our workforce should mean that we don’t spent time doing simple things that can be handled by computers. Sometimes it’s not easy to decide if the automation or tooling is necessary, but at each point we ought to consider the cost of building and maintaining some solution over the cost of an individual spending time there. Often, though not always, we can find a little software development saves a lot of future costs.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.