When DevOps Went Wrong

A short ”state of DevOps” type analysis of current software industry through my own experiences.

DevOps as a silver bullet...

First of all, don’t get me wrong. I love DevOps and see that as a perfect tool for the problems that we currently face in software development business. The sad fact is that DevOps came and will also go, sooner that you might think.

Throughout the history mankind have had need to do inventions in business to keep offering value to customers faster than the competition. The first innovation in industrial age was the steam engine around 1700, then came the moving assembly line by Ford in 1913. Assembly line was followed by the Toyota Production system (TPS) around 1950 and Theory of Constraints (TOC) at 1984. And then  came the software and we have already seen Waterfall process model, scrum, xp, Kanban, SAFe, Less, Lean, Agile, Systems Thinking and latest but not least DevOps within only 30 or so years period. So the pace is definitely getting faster and faster (means that the DevOps is out of the door sooner that you know what hit to you) but one thing will still remain.

The thing that remains is the core idea of all methodologies above, the core that is shared by all is the idea that the organization needs to learn faster than the markets to be able to provide value faster than others. Latest methodologies are calling this learning a “Self-Learning Organization”. When studying those methodologies above, learning is “the” core value that pops out in each of those with a different wording and period accurate descriptions. But it does not take away the fact that learning has been, is and will be the key.

Dropping the ball

Modern software organizations have learned quite well on how to get rid of the old, “not suitable anymore” waterfall methodology and moved to more agile waters. There surely is no shortage of consultants telling the company’s business that Agile is something that they want to be and the way that they need to run their companies.

So companies started quickly to transform their selves to agile model and soon after that realized that with all the old went also the last vague visibility to the actual function where the rubber hits the road, the development. After all, all agile methodologies states that “let the development do their work as they please… they will deliver!”.

The thing is that I have read many books about these methodologies and attended many conferences about those and all those methodologies tend to describe quite well the business process and how it is done BUT they all seem to drop the ball in the exact same place that is what comes beyond the User Story level. With User Story level I mean the level of items that development should be able to produce. These methodologies mostly just claim that team moves this black box from to-do to done, that’s it, simple as that. But what happens when it is not just “simple as that”? What happens when the development starts to lag behind, produce buggy solutions and just do not perform?

Irony of modern software work

So the business got Agile and is now capable of ordering double, triple or even ten times more features from the development but results that they get are very bad or fluctuating. The irony is that the much picked business just become faster than the cutting edge development. This is very frustrating situation for the business since the only thing that they need is the speed and predictability that should lead to constant flow of items from the development.

In ideal world the development will also organize according to one of the modern ways (DevOps preferably) and speeds up their part of the equation to match the business speed, but in most cases this is only a dream. If the development is not performing, business is willing to go great lengths to find and offer suitable methods to the suffering development. Nowadays this usually means hiring a “DevOps team” or setting up a “DevOps function” or even hiring a “DevOps Architect”, just to get the development engine running. The Irony here is that DevOps is not a team, function or role. It should be a mantra that the development embraces and adopts.

But what happens if the development do not want DevOps? What if the development refuses to use these new methodologies and hangs in the old world with their teeth’s and nails? How can this be possible?

The new standard for factory work

In old days developer, “a hacker”, was a person that had great satisfaction of just trying to do something new with code, use it in places that was not meant to be used or managed to shave word or even one character out of the code without breaking the functionality. These guys took great pride and joy about their work and were willing to fight for it, till the end. Back then the number of hackers (developers) was only few and the whole industry was considered as art.

Nowadays everybody needs to know how to code and most of the work available requires some form of coding. This means that software development is becoming a new form of factory (modern feature factory) work that one “just does from nine to five” and then goes and does the things that one truly appreciates. This means that we started to have developers that do not care so much about what they type or do, they just work here.

Business making it worse

Basically it is a societal problem if we do have 80% of our workers that do not want to learn and considers software work as a meaningless factory work. But still there are two things that business is not knowingly doing that harms greatly the situation.

First thing is when business speeds up the pace and starts to triple the amount of orders from development, that pushes the development focus even more into the features and not for the improvement work that needs to be done…eventually.

The second thing is the whole idea of subcontracting some part of their product, and to be more specific the contracts that are made with the subcontractors. mostly those contracts describe only that “a specific functionality must be provided”. Why should the subcontractor want to add testing or think about the architecture if it takes 40% more time and resources to do that? It wasn’t ordered after all…right?. This might even go so far that the company is paying for the subcontractor for the extra hours of fixing buggy code. That is a solid form of revenue so why change?

How to fix

In this point you may start to think that “wait, we do not have a problem with DevOps, it works like it supposed to work and everybody is happy”. If this is the case, congratulations, you do understand how to use it and how to take most out of your organization. I only wish that there will be more of you thinking the same way in the future.

But for the rest of the organizations this is a good question and unfortunately I do not have a good answer to this. In short term I see that the companies needs to go through their subcontracting agreements and fix those. Companies need to also let the teams take the time to make things right and fix the situation. This will hopefully stop the vicious cycle and let the tings heal and get better gradually.

In long term I see that something needs to be done for this 80% of “just working here“ employees. They need to think how they can engage and switch whole personnel’s mindset to the continuous learning mode to actually innovate beyond these methodologies that how to be faster than markets in their our own context. This leads to true learning organizations and companies that will stay in history books (for good reasons).