Culture, schmulture. DevOps, agile need to be software-first again
Decades of preaching about meatware complicated dev life
A common story from this era is the fateful day one of the programmers is selected to "run the servers". Shifting over to "ops", the programmer either goes mad, or starts doing what any competent programmer does when faced with a new problem: procrastinating and drinking. A few weeks later, they look at all that infrastructure as something to program, and start coding.
For me, a 2009 talk by Andrew Clay Shafer codified this thinking right around the time it was codified into DevOps. To a room full of agile lords and ladies, he proposed something wild and crazy: what if you were responsible for how your code ran in production? Perhaps you should start to understand, embrace, and improve that phase of your software's life.
This implied focusing on the people in the software development process and how they work together and behave. The people are just as much a part of the application as the software and the hardware.
The idea of a "blameless postmortem" is a good illustration: in innovation mode, things are going to break and go wrong as you charge into the unknown. Systems will go down catastrophically, but you can't simply give up, and punishing people just takes you back to the overly cautious state where software is released infrequently. So, as described by the Google SRE book, you instead celebrate failure, even telling the entire company the harrowing tales of what went wrong and, importantly, how you fixed it. Of course, once fixed, the key is understanding the problem well enough to put new policies, practices, and technology in place to prevent the problem from happening again.
As this type of navel-gazing continued, organisations once again discovered that most of the problems were caused by errors in the human systems they'd built, the meatware. Technology was an issue, to be sure, and there's a parallel story about how the evolution of what we now call "cloud" provided an ongoing arsenal for all this, with exciting distractions along the way with names like J2EE, rails, and WS-Deathstar.
People, though, were still the consistent problem. They just seemed to keep screwing up all this agile stuff, if they were actually doing it at all. Most still clung to the false comfort of big upfront planning and its illusionary promise of hitting The Date.
You'd see the effects of this backsliding in instances like the US's rollout of healthcare (saved by, ironically enough, a bunch of "cowboys" from out west). The private sector was, and is, no slouch at resisting agile either: they're just good at hiding it. The difference between them and the government is that enterprises can change more quickly when they're threatened. The "culture" at enterprises is more hopeful, perhaps, at least once backed up into a corner.
Just as the goofy social companies of the 2000s had to compete on innovation, large enterprises now feel the pinch from the numerous ankle-biting disruptors that are having a good go at eating the incumbent's lunch.
You see this reflected in executive comments in numerous quarterly calls. Some of them toss-up effortless word salads of "digital" and "omni-channel", but others have clearly considered their strategies and are applying a software-first approach to business. While they may not know exactly what to do, most executives know they need to start doing something. As JPMC's CEO said a few years back: "Silicon Valley is coming."
So that's where we are now: from Chrysler's HR system, to keeping Twitter up, streaming videos and sharing pictures of cats, to the very real need of old-school multinational, global enterprises to compete based on software.
Surveys show how shaken executives think the situation is, with many doubts that IT's not up to the task of transforming to the point where they can reliably create, refine, and run software. They know from experience that outsourcing doesn't work, so they're looking at their people, organisations, and technology. There are early indicators that it's working – tales of using this new software-defined business approach to insurance companies cutting the claims process from a week to less than a day and doubling the industry sales average – but there's a massive amount of work left. Hopefully, we won't back slide this time. ®
We'll be covering DevOps, agile and continuous delivery next May at Continuous Lifecycle London, 2018. Early details, including information on submitting a paper and becoming a speaker, right here.