„Simple Task Kanban“ von Rakuten, Inc. - Eigenes Werk. Lizenziert unter CC BY-SA 3.0 über Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Simple_Task_Kanban.jpg#mediaviewer/File:Simple_Task_Kanban.jpg

DevOps – An Old Idea With a New Name

More than ten years ago we were working on critical globally-distributed business systems with methods that nowadays would be called “DevOps” and “Cloud” computing. There really is nothing new about the technology, and truth be told the last great innovation in IT was the USB stick.

USB sticks are of particular interest due to their use of quantum tunnelling to store data, with all the concomitant overtones of non-locality. Which if you’ve read-up on Alain Aspect’s experiments with single photons emitted from Calcium atoms, you will appreciate as implying that if the Universe is one of gravitationally-curved space-time as described so elegantly by Einstein’s Field Equations, then it cannot be objectively real.

There are dissenting opinions on this, but physicists are yet to prove that the Universe actually exists in real objective terms, and the evidence provided by Aspect strongly suggests that it does not. Or perhaps everything we thought we knew about it is wrong.

Everytime we store data to a USB stick we have to start wondering if we’re really doing it or if the stick, the data, and even ourselves are not simply figments of the imagination. Perhaps even our own. Subjectively though, we stored some files. Which is what USB sticks are designed for and one really doesn’t need to ponder the deep philosophical implications of the technology in order to use it, no more than you need to understand internal combustion engines or force vectors to drive a car.

That said, if drivers did understand the physics of how their cars work they would most likely crash them far less often. So it goes with software developers and their applications.

Considering that everything we think we know might be wrong is usually the best place to start with any task, but it does not apply to Agile developers because they already know everything.

Demarcation

We’ve already written on the sometimes mandatory need for walls of separation between development and production in our article Operation DevOps. With this article we prefer to look at the business back-ground to the fad.

Nowadays so-called “professional” developers are considered qualified if they have completed a two-day course, and after a mere two-years in the job are considered senior. This is necessary in order to cut costs, as people who are not really qualified to do a job will have no idea how much they should be getting paid for it and will be easily impressed with lofty-sounding job-titles.

How many Agile developers are aware that the industry-standard fee for a professional software developer with two years experience is $240 per hour? Do you know anybody in Agile – apart from the certificate salesmen and women – who make even 1/4 of that? But that’s how they are being charged out by their employers. This figure includes the overheads of providing them with a cubicle, PC, software licenses, sick and holiday pay, and most important of all the CEO’s seven-figure annual bonus.

Overheads

Overheads which are eliminated, CEO bonus excepted, when hiring independent professionals who maintain their own development environments and can work and collaborate remotely – which Agile expressly forbids as impossible. To be Agile, apparantly, you always have to be in the office, on time, and with no exceptions.

As in all professions, one’s ability as a developer can be measured by how much you are getting paid for it, and Agile developers are amongst the lowest paid in the industry. Which is not surprising when one makes an objective examination of the quality, or lack thereof, in their work.

It is Agile that spawned DevOps. The same cost-cutting corporate mentality who wish to cut out the deadwood of computer science professionals who expect to get paid, replacing them with enthusiastic under-skilled muppets who are happy enough simply to have a job and don’t care so much about pay. For the low-skilled any pay is good.

Back in the last decade we were deploying fixes, fully documented to SOX-compliance, onto running critical systems during business hours, frequently within 12 hours of the problem being reported and always requiring the close collaboration of a globally distributed, and frequently ad-hoc, team to ensure there would be no downtime.

We were reasonably successful in this endevour that by 2007 the business had more than quadrupled their revenue mainly by the intake of new customers who had left competitor companies attracted by the impessive uptimes and performance we were recording. When rival companies’ B2B systems went down, during particularly intensive periods of market activity, ours stayed up. What better way to drive customers to your business than by remaining open when the others have closed?

We would often be running planning conferences on the fly, with the people involved scattered around the world. We had an agreed escalation plan to bring in whichever people who were both available and had the required skills, along with senior business leaders from the units affected upwardly delegating decision-making powers to them. Some participants would be talking from their bedsides because it’s 3AM, others dialling-in from their cars after pulling over to attend to the business emergency while they were driving. Some working from home on-call, and maybe even some people in the office in whichever region happened to be experiencing “office hours” at the time.

Things Got Done

That’s how things get done when you hire skilled people who know their own responsibilities and can work together as a team irrespective of whether they actually know and like one another or not. Working successfully with people you neither know nor like, and to be able to do so at a time that is perhaps not quite as convenient for you as you would have liked, is what being a professional is all about – we call it ‘detachment’.

Our focus is on the job that needs to be done. We do not waste our time trying to redefine what ‘done’ means, nor do we interrupt the emergency to complain to our managers that we don’t like the DBA. We keep the business running, we get paid, then we go and do our own things with people we do know and like.

Agile practioners, on the other hand, are more focused on themselves and their percieved popularity. They will indulge in finger-pointing, whining about team members they don’t like, refusing to work with them, dehumanising them as “toxic”, and demanding they be fired, no matter how critical their knowledge might be to the project.

Now we look at the “continuous delivery” of DevOps, with it’s same “there are no experts”, “everybody does a bit of everything”, Agile mentality who are typically reporting that it takes them “several months” to deploy a bug-fix.

Why are we not surprised?

They hire lightweights on the cheap, they deploy to third-party platforms that nobody really understands instead of managing their own, then they wonder why it takes months to get anything done.

On the other hand, if all you’ve got to offer your customers are throw-away apps where ownership is considered more important to users than usability, then Agile and DevOps is definately for you. Why bother bug-fixing after you’ve already got the customer’s money? It doesn’t make sense.