Everybody has their threshold, the point where the nice shiny new DevOps process goes out of the window and it’s just easier to do it the old way.

I reached mine at 7:15pm. After hours of struggling with deployments, it was just easier to change the code on the live site and commit it to source control later. That brilliant new Continuous Integration pipeline went out of the window and was replaced by a copy of Notepad. I knew it was wrong, and I felt bad afterwards, but I did it anyway.

When we cross this threshold we try to justify it to ourselves; ‘it was too urgent to do it the proper way’, ‘it’s OK just this once’ etc. But the truth is, it’s not our fault…

Humans are lazy, developers are efficient.. we are both.

Humans are programmed to be lazy. Why expend needless effort doing it the long way when we can do it quicker and move on to something else? We will always tend towards the path of least resistance.

As developers, we spend all day looking for the most efficient way to do something. That usually means the easiest and fastest solution to the problem at hand.

We can resist these instincts for a while if we know the harder way is the right way, but that will only last for so long. When our back is against the wall and the pressure is on, we will always cheat.

The 5to5 test

With that in mind, I would like to propose a new metric to measure the maturity of a DevOps process. The ’5to5 test’.

The test is simple:

When it’s 5 minutes to 5 o’clock on a Friday afternoon and you need to get home for the weekend, is it easier to use your new process or just do it ‘the old way’?

Passing the 5 to 5 test.

There are two ways to make sure your process passes the test; make the new process easier or make the old process harder.

By making the old process harder, you force developers to abide by the rules.If developers cannot access the server, they can’t change code on the live site. If you don’t physically let developers out of the door until they have committed their code then it won’t remain on their local machine rather than in the repository.

I would argue, however, that this is neither sustainable or sensible. If you have to enforce artificial barriers on developers to coerce them into using your new system, then it is not mature enough to completely replace the old one. It doesn’t mean that the new way is wrong, just that it needs more work to make it the default behaviour.

The more sensible solution is to make it so easy to follow the correct way, that it becomes natural. For example, I failed to follow the correct process because it would take 10 minutes to go through the Continuous Integration pipeline and get my code on to the live site. It doesn’t mean that our CI solution is wrong, far from it, it just means that it is not mature enough yet to be the default action by a desperate developer under pressure.

I don’t know if it’s possible to every make any DevOps process easier than ‘cheating’, but that’s the goal we should be striving for. Perhaps, if it was possible to deploy my code through the CI solution in only 5 minutes, I would have held out another hour before reverting to Notepad. That’s not perfect, but it’s an improvement.

How many of your DevOps processes would pass the 5 to 5 test?