Tag: DevOps

I’ve been writing, talking, and practicing DevOps for nearly 20 years. It wasn’t called DevOps back then, but in the early part of this millennium, I worked in a software team that embodied many of the three ways of DevOps.  We made small changes, we worked rapidly in short cycles, we adapted to our business needs, and we released often.

And we included the database.

At the time, this was a small team of about 15, and I had good control of the database processes, able to influence, debate, and demand our developers improve their skills regularly. We didn’t think about the database as anything more than one more challenge to overcome in order to build and release our software rapidly. Others feel that way as well and the ACM notes that a SQL database is no excuse to avoid DevOps.

This articles covers many of the things I’ve been preaching for some time. We use automation, we adopt good techniques, we instill discipline in our work, and we continuously improve. The article provides a few techniques for using deploying database changes. I do think some of these are good ideas, but as with many things, the devil is in the details. This is a high level look at what you want to accomplish, but the actual mechanism for making changes will vary, depending on your environment.

My employer is constantly searching for ways to improve database development, and we follow many of these techniques in principle. We recognize that testing and deploying changes needs to be easier and more reliable. As we build solutions, I think we’ve helped customers in many ways, however, my fellow advocates and I continue to preach a few things not in the article.

First, we need to continue to improve our code skills, which include data modeling. Moving faster doesn’t mean we get to shortcut good design principles. Second, everyone working on software touching the database needs to work closely together. The data is the most important part of this process, and we can’t afford to let anything happen to it.

I implore you to become better code writers, better software developers, and better team players. I also encourage you to look at DevOps as a set of principles, not as something you buy or install. Like much of life, adopting DevOps is a journey, just like your work with SQL. I’m sure that journey isn’t complete.

Steve Jones

Note: Podcasts paused this week as I have construction taking place at the house and nowhere to record.

I’ve worked in a a couple very high performing organizations that adapted to changing conditions and built software well. I’ve worked in more poorly performing organizations that struggled to release updates and patches, causing tremendous stress for the IT staff.  DevOps is designed to help improve our software delivery and quality, if you work on improvement in many areas.

I saw a post on LinkedIn, from the Chief Architect at HSBC bank. This was interesting to me because I see HSBC ads constantly when I travel to the UK. They’re the 7th largest bank in the world and was founded in 1865. If ever there was an organization with lots of legacy everything, this is it. They have every reason to do what they’ve been doing for years, since it’s worked out well.

The post notes that Jez Humble, well known DevOps author and co-founder of DORA, came to talk to them about software delivery and DevOps. For the author, the highlight of the day was the CIO giving this challenge: “… setting every team the goal to double, half and quarter every year: double the frequency of releases, half the number of low impact incidents, and quarter the number of high impact incidents.”

That’s an ambitious goal, and as the post notes, this results in exponential improvement year over year if the team can achieve this. I think there is likely some limit to this, based on team size and application complexity, but certainly when you’re going from a mid range performing software development group, this isn’t bad.

I like that this goal was set not just to increase deployments, but to also prevent incidents. I think too many managers look at speed as the goal, without requiring quality to improve. This goal doesn’t quite address this, unless the impact incidents include bugs and poor performing software. It can be easy to limit incidents to downtime from deployments, and not necessarily the use of software.

The hands off management of this approach is good as well. Not specifying how this gets done. Leave it to the technologists to get this done and hold each other accountable. With that kind of support from management, I’d hope most professionals would step up, improve process and quality, and take pride in their work. It seems to have worked as HSBC, as they’ve been written up a few times in their DevOps approach to IT. I think it can work anywhere with the right management approach.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

I caught a link to the OSS’s Simple Sabotage Field Manual from David Perell. It was written as a guide to destroying organizations during WWII to be distributed to citizens of enemy states. The OSS later became the CIA, but their goal was to find ways to disrupt the governments of enemy states.

What was surprising to me was that some of the advice seemed to still be in use in places I worked in my career. Such as the advice for managers: ” To lower morale and production, be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers; complain unjustly about their work.”

This might seem to be human behavior, and it is, but it also destroys organizations. Too many people in authority don’t seem to do a good job of evaluating those that perform well and drive our software forward. While I do think this is subjective, often the group view from workers and the managerial view of who is efficient can be quite different. Being transparent and open with expectations and evaluations can help here.

Working in committees and large groups is all too common, at least in US organizations. We hold meetings and have discussions with large groups instead of making decisions. I do agree with getting opinions from a large group, but discussions should be relatively short and then decisions made. We don’t want a dictatorship nor a large democracy of debate, but something in between.

Maybe one of the more interesting ideas is the work slowly. I don’t know of many workers that want to work slow. Some do, and sometimes we all struggle to get things done, but so often management doesn’t want to invest in tools for workers. Tools can make a job much easier, and much more efficient. Part of DevOps is learning to use tools and become better. Or fabricate your own tools, something we can do in software easily. Too many managers don’t want to budget time or money or build or buy tools.

It’s easy to self sabotage ourselves, and too often, it’s easy for managers to destroy an organization from within. This might be an interesting manual to review in a meeting and debate if our rules, protocols, and decisions are helping or hurting our organization. Unfortunately, too many managers aren’t willing to perform that self-evaluation.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.