‘Fix Me’. Or How I Learned to Stop Worrying and Love the Ops by Tom Moran

Throughout my transition from solo programming to DevOps consultant, I heard one consistent answer to the question of what DevOps actually is: “It’s a philosophy”.  Be it on my own prejudices, that answer has never seemed sufficient to me. It conjures an image of IT professionals smoking pipes and pondering “If a server crashes, but there is no monitoring, did it really crash?”. It is not that I disagree with the answer; DevOps is a philosophy, and it can even lead to some grand ideas. Large-scale projects become a series of dynamic releases supported by continuous planning and monitoring. But what does it mean for me as a DevOps engineer supporting the infrastructure of a client. How has the process of writing and using code changed now that the code is part of a wider operation.

When there is no monolithic program to create, the DevOps philosophy can end up a lot more modest. It becomes continuous, incremental work with a keen emphasis on collaboration and documentation. The small improvements I would come up with and attempt now have to be written up in a ticket, with regular progress reports also recorded. Detailed instructions replace merely trying to remember how a program was designed to work. A git repository is not just a back-up of the code anymore, it is a web of feature branches and merge requests that need reviewing and approving. This is what the philosophy means to me currently: following proper procedure with all work to inform those using the code.

It may just seem like good team practises, and it is. It might seem like extra work, and I have certainly felt like that. “If I am writing the code for me to use, why do I need an accompanying page of details and instructions?” Maybe I had not spent enough time pondering The Zip File of Theseus* to really comprehend why we had the philosophy in the first place. Or, at the very least, I had not had the experience that I am leading up to here. An experience that emphasised the importance of all the little things we do to allow us to combine the words Development and Operations.

A Small Improvement to Existing Code

On my current client, there is a particular program we run about once a week. The code calls another script to compile files and then automates the sending of these files to a user. It is kept on a secure server that we sign into and run the command, without needing to look under the hood any further. The code itself predates our involvement with the client, but we inherited it when we arrived and are now responsible for its management. So, when one of the program’s dependencies was upgraded, the team added an improvement ticket to add a new feature to the script. I chose to take up this work.

Most development work, particularly when looking at a project for the first time, will require a little research to start. This was, however, a little different. I found no documentation explaining how the script worked. I found no evidence of the evolution or writing process for the initial code. I could see the code but without an understanding of the thought process behind it every line would need careful consideration. After more than a little detective work I had absorbed each step to the point where I needed to add a new feature. It was then that I found it: a decent start at the work I had to do, ‘commented out’ so the script would skip it and it would not break anything. Above this, a two word note: “FIX ME”.

A day of scouring through the system had culminated in the rather frustrating conclusion that someone had already started on this work and had got halfway there. I was not adding a feature, I was amending a piece of code and I had not realised until now. This is not to cast aspersions on the person who left that note, or the incomplete work, or any of the work for that matter. The work done here deserves a lot of credit even if I did not feel like offering it on that particular afternoon. To do so now, I think it is best to address the most important portmanteau in my life: “DevOps”.

Dev + Ops

In its simplest form, when one developer sits down at a computer, ‘development’ is writing a piece of code to complete a task. The ‘operations’ in this case is me running the script on the server every week, and checking everything is in place for the code to work as expected. When we took on this process, these two were entirely separate. The ‘Dev’ had been done – ‘FIX ME’ notwithstanding – and allowed the ‘Ops’ to work as needed.

To be clear, the Dev I found on the server that day was very good. It took in a number of complex processes and returned a working package that it sent automatically for me. Despite running the script often, it is yet to fail on me. I was not coding 3 years ago, let alone writing code that could withstand the test of time. Leaving yourself a note of “FIX ME” for later is not a bad practise either. That is a searchable little phrase a developer could use to find any piece of code that needs some more work. A developer worked hard to make this all work.

It is when I tried to combine the two – Dev and Ops – that the need for the philosophy was highlighted. I had been using this code for months, without any trouble, but now I had to use the knowledge of its operation to inform the development. This is where all of the extra steps of DevOps would have been useful, even if I would forgive someone for not having the time to follow them. Clear documentation on how the script worked, and what it required, as well as a history of improvements kept in a repository would have benefited me on that day. Not just in using the script, but in improving the script with further development.

“This is your code now”

One of the more senior engineers says this to me everytime he shares a piece of code with me. I’m not sure he realises I see it as more of a threat than an invitation. I am now responsible for this code, and to fix any issues that might arise. After I had addressed “FIX ME”, I started to understand what was really meant by this statement. Code had been developed by someone who had every intention of continuing to work on it. In time-pressured situations, or solo work, it can seem like all that matters is your code. However, as soon as our team started using the code, and as soon as I opened that file to read it, it was no longer their code. It was my code as well.

The philosophy postulates is that code ownership is not a static concept. Once I was operating that code, I became its owner too. “I tinker, therefore I am”. I spent a day applying all the procedures I mentioned for this one small development script. Those who use the code can now find a write-up of everything I learned. I applied my changes to a repository first, so the history of the code can be reviewed by others who work on it. ‘FIX ME’ is in that history. A tribute to the good development that came before me, but also a reminder to myself of how best to make my most important portmanteau. How DevOps is about the operations informing the development, as much as it is the other way round.

* “If you replace every file in a zip package one by one, is it still the same zip package”. It’s The Ship of Theseus, but it is also a very bad IT joke. And I am sorry.

Our DevOps Transformation and Delivery services are unpinned by our unique DevOps Academy. Want to learn more? Click here.