DevOps for effectiveness, not efficiency
Collaboration of both software developers and IT specialists image via Shutterstock
I started coding for real business and high traffic approximately 25 years ago. We used emacs (or vi or … insert favorite editor here), we scribbled some architecture diagrams. Build was done with a makefile. Then we built some deploy scripts (to be honest we didn’t even call them that at the time). We always managed to get the stuff out. Our main issue then was building the right thing – across the whole team. Somehow I took some lefts and rights in my career that led me in another direction. When I came back, I was closer to emacs again but things were different: There were ops teams, people specialized in deploying things. A friend of mine worked at a huge company for half a year, just getting a java deployment pipeline right.
When I started, everyone’s concern in the team was to “build the right thing” or at least “build the thing the client thinks is the right thing”. Actually, our main job beneath the surface of building things was to help the client find out what to build. When I came back, the division of work between business guys, 25 kinds of developers (front end – back end first, then QA, then OPS, you name it …) led to development being just that: development of whatever. OPS being just that: Operations. Operations of whatever. A consultancy I worked at even offered development services you could order at a specified CMM level (I guess Level 1 – chaotic” was not offered ;). So whatever was ordered was delivered the required CMM level. No questions asked, of course. Not even an essential one: Did that software really make sense?
Hold on! This is not supposed to be a rant about how things were better some time ago. To be honest, the level of software development in my days, the opportunities that libraries, frameworks offered were lame compared to what can be done. What could be done in the web now feels like HTML 0.3. I am just telling this story to be able to pinpoint the chances of DevOps in my view. And also where some dangers are.
On a technical level we were basically crap at that time compared to what can be done today. What we did had to have a certain integrity – simply because our team was integrated.
What happened then, I guess, was breaking teams apart for two reasons:
- Raging technical progress made it hard to follow up so maintaining the necessary skills to remain a “full stack developers” was incredibly hard.
- Specialization also made it possible to divide operations —and not inside the teams. But a harder reason to do that was this: some bean counters in front of some nice Excel sheets whose calculations screamed at them that dividing that integral work would be cheaper. And this, of course, is an issue that goes beyond our industry. Wherever you look, bean counters around the world calculate based on Excel spreadsheets that only map half of the economics for one but – worse – that cannot capture quality of products and experiences. As a result, we receive crappy products and services that provide mediocre customer experience. What gets lost in those products and experiences is what Christopher Alexander calls the “Quality without a name”. It is what makes customers love our products rather than just use them.
You can see that anywhere: Conception of products is carved out of the main team, UX is yet another “phase” – again specialized into 25 sub-disciplines of UX. Hence LeanUX is another attempt to integrate back what belonged together all the time.
This is how the pendulum in any industry swings back and forth from breaking something sensible up in silos, realizing what gets lost and then swinging back to integration. In most cases, swinging back is a grassroots movement. That explains why we have to deal with resistance.
So, our chances are clear: we can bring back the quality without a name. We can reduce handovers, create quicker, better feedback loops. We can bring more fun back to work!
But there are also risks: DevOps itself is also a local optimization in the larger framing of a company. Having the button to push so each feature is immediately brought to life is a great industrial capability. It still does not guarantee that we are doing the right thing. Here are two main dangers of DevOps:
- Risk and oversight number is that we only use DevOps mainly to do things better (efficiency). Great companies’ focus, though, is effectiveness: to do the right things (and, of course, do them better). In our ambition to integrate ourselves again and only looking at efficiency, we could actually be in the way of people who want to already do the right thing. An example would be a redesign of our site where we get impatient just because we work in sprints and can easily deploy anything.
- Risk number two is that we create a silo and thus represents a hindrance to global optimizations.
What we have to do is to strictly align to the strategy and purpose of our company. We are not a redefinition of our company, but simply of how we run things down here. Of course, by being great at what we do, you can have a huge impact through all the options, you can infuse into the strategy and feedback loops on all levels. But first you have to really and deeply understand and engage with purpose and strategy.