DevOps Driven Development - Delivering deliverables deliberately

Tue Dec 18 18

I have a confession - when I first learned was devops was, I thought it was really cool. It seemed like a magical world of configuration files, and matrix-style watching green text flying up the screen as cryptic tasks were completed one after the other. The end result being a satisfying set of boxes turning green as your servers come online with your software product fully working and updated to the latest version.

The more I understood of delivering ops though, the less I considered it a job that should be separate to software development (hence DEV ops I suppose). A group policy that must exist on chrome is as pivotal to the software's function as the cname of a linked SQL oledb instance. The problem I find with devops though (apart from it not being taught in any capacity at uni) is that it doesn't feel like useful software development when you're doing it.

In fact I would describe it as

  1. Being the end user for someone else's software (frustrating!!)
  2. Fiddling with knobs till it works (I'm looking at you IIS)
  3. Configuration hell

A problem with ops can be so many things that it's easy to lose hours upon hours researching computer security features until you finally get it. In fact I would say there are so many things that can go wrong with ops that it's a minor miracle that computers work at all. In any capacity. They do though! The reason they do is because countless people have worked tirelessly to make it just work. When it breaks it gets fixed by a friendly IT guy / professional and then it just continues to work.

The journey from a computer noob to a computer pro eventually includes learning (at some basic level) the full range of a computer's feature set. Windows error logs, that one setting you always need in IIS 7, where it got moved to in IIS 8, what do all the tabs do in the security panel in explorer etc. This is before you even do your deep dive on your SQL provider (in my case SQL Server) and get bewildered by the 10,000 features it's capable of (SSIS, SSAS, SSRS, OLE connections, Agent jobs, Profiling, Execution Plans etc). This is before you've even touched on the zillions of library APIs that your code glues together and programming methods (WPF/MVC/EF blah blah...)

In fact, one of the changes in mindset I had at some point between writing my first line of python code and today is that I no longer feel like "a programmer" or "a developer" and rather "An advanced computer user". My job is not just formatting code files with correct algorithms, it's making the database work, making windows stop crashing, making the email subsystem accept the nonsense my users want. Even the act of constructing code is really just a friendly suggestion to msbuild of how I want the computer to function. Msbuild is just a program somebody wrote which takes in a text file, applies a zillion flags and features to it, and outputs working software.

To outsiders of course, constructing code files is the most intimidating and "complicated" part of development. I disagree. Constructing CORRECT code files that work in the environment you want it to consistently to all customers is the most complicated part of development.