DevOps: Accelerate software not human
# Coding is easy, building complex software is hard.
Coding your first line, learning your first program and starting to get result takes few weeks to some month, how exciting! In that regard, coding is easy to learn. Welcome to the beautiful world of developers.
After getting started with your new position you will start to hear questions regarding your code like:
How to interoperate pieces of software? When and how to design API? How will my code look like at runtime? How to tool my piece of code to be observable? How to enable end to end tracing? How to document both features and codes for everybody involved to be able to participate? How to react to failure or shortage of services? How to store the data, in which format, for which kind of queries? How to display it to none technical user? How to make a feature available in a nice manner to users?
Feeling overwhelmed? those are just few examples of all the questions that revolve around a bunch of line of code which will live for years somewhere within a data center.
Feeling overwhelmed by them is totally okay. Coding is easy, engineering and building complex software across a group of people and to the world is hard.
# DevOps culture and automation to the rescue right?
One of the principle of devops is having small changes. Such changes allow us to answer those question one by one against a context we, as human, can grasp.
This way we won't tool once our entire codebase but do it slowly for every bit of software we release out in the world.
Another cool thing about small changes are the fact that it is easier to manage for the whole development chain, bye bye long night deploying thousands of new line of codes and dozens of features. Now that you have small chunks of changes you can deploy in less than a minute. On top of that you can safely automate it!
Congratulation you can now gather feedback around a feature in less than a day and react as quickly... Or can you? Did the capacity to accelerate deployment and iteration actually change how fast, as human, we can react to that mountain of information lying in our observability systems?
# The human brain didn't become faster
Here goes the trap, now that the whole toolchain is as fast as computers can be to test, deploy and monitor your software, making a change should be as fast right?
In reality, it pushes the pressure from deploying once during hours to the everyday developers' life.
But the pace of our everyday life didn't change. It takes the same amount of time for human to design a feature, investigate a database performance, read a blog article or learn an entirely new framework.
Selling DevOps as accelerating and enabling people isn't fully right in the end. DevOps pushes some complexity out of the developers way but brings new one that challenges our time management and at it's core the time we have to stop and think about what we are doing, what we are coding, how and why.
# It's time to stop and think
I am not advocating against DevOps, I wouldn't code any other way now that I embraced it but that set of practices should be put in it's right place, not in the way of our time as developers. When aligned to the company or team culture, DevOps should actually free developers, product owner, designers and sales some time to gather, stop and think about what they are doing and selling and that time is incompressible whether we like it or not.
Us as developers should embrace deploying as soon as it is ready and get comfortable about having automated integration steps to have a safety net around our probable mistakes. This, on the other hand should not prevent us from taking the time to think our code through.
Let's respect our human pace and our limits regarding how much data we can consume or how long it takes to discuss our software. This way we can take the right decisions and iterate toward the right direction.