Tag: DevOps

A few weeks ago I wrote about the bus factor. This is the number of people that could cripple your organization if they got hit by a bus. Maybe a better way of looking at this is the lottery factor. If these people won a lottery and quit, would they cause problems? There were some interesting answers in the discussion.

There is another factor that I heard about in a presentation that I found interesting: the Lunch Factor. This is the number of people that have to get involved for you to deploy changes to production. Today, I wonder what your lunch factor is? Leave a note in the discussion.

This may be one set of people in your organization for things like patches, which are supposedly tested and approved by the various vendors you use. For software that you develop internally, likely there is a slightly different group of people, with some overlap. Usually the Operations staff is the same in both situations.

In a true DevOps organization, the idea is that developers can actually release code to production. Maybe not every developer, or not every developer can release every type of change, but the idea is that developers can, and do, release code. They’re also responsible for this code. In my discussion with Donovan Brown and Abel Wang of Microsoft recently, this is how they view the world.

They also would likely have most code released triggered and controlled by feature flags, which might ensure that customers can’t see the code right away, or that the code doesn’t break existing customer work. This also ensures that you can turn the feature off if there are problems. I’m a big fan of feature flags (or feature toggles) and think they are way too underutilized by many organizations.

Allowing developers to release code is difficult for many managers, and even for Operations staff. There is always the worry that developers don’t have the expertise or accountability to make these decisions, and many orgs don’t have the capability built in to allow this, much less give the authority to a wide group of people.

Microsoft does, as do lots of organizations trying to embrace DevOps and produce higher quality, more adaptable software. Many of these companies are bound by Sarbannes-Oxley and other regulatory rules, and they make it work. They grow, change, adapt, and most importantly, constantly improve their systems and process to allow this. For them, the lunch factor is 1, or maybe 0 if you consider that no one needs to get taken to lunch. What’s your factor? What staff, managers, even change control boards have to get involved? Let us know today and then think if you could reduce that number.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

When the COVID-19 Pandemic grew rapidly in early 2020, medical supplies were in short supply. Different areas and organizations struggled with different types of issues, and one of the higher profile issues was with ventilators. In March, the projections were dire and quite a few hospitals were worried about the supplies of these devices. This was especially disconcerting given how many people were being placed on them and how long it takes to produce them.

I met someone at that time that said getting a car company to produce these wasn’t possible. The factories were specialized and converting machinery and people wasn’t something that could be done in months. This was someone that claimed to have over 30 years of manufacturing experience.

I had no basis to argue, though my instinct was that we have mobilized large industrial efforts in the past. When I read this article recently, it made me think about that conversation. Microsoft worked with a number of manufacturers to produce ventilators quickly, up to 400 a day in the UK. The story is interesting, and it shows that engineers at companies like Ford, McLaren, Unilever, Rolls-Royce, and more can not only work together, but also focus their efforts in a crisis. With the help of technology and data, they transformed a manufacturing process from the ground up to meet the needs of the UK.

If you watch the video of the effort, it is amazing to see just how knowledge and data are brought together to ensure these devices can be built quickly, and at a very high level of quality. Certainly some PR is involved here, but the keys to success in producing something are the knowledge and skills being applied to a task. Products like dashboards and the Hololens help to move knowledge around where it is needed. In building software, tools like Live Share help to move knowledge from one person to another.

The coordination of people working together, driving to a common goal, is critical as well. DevOps asks us to practice this, choosing to be a team, with the goal of increasing quality while we focus on delivering software to customers. This is a great story, but one that highlights things that many of us could strive for in our daily work.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Last month I did a webinar with the ATARC group on DevOps and databases. I was on a panel with a few government employees talking about the COVID-19 pandemic and how this may have changed work inside the US government.

One of the panelists is a full stack developer for the Smithsonian. Ravyn Manuel talked a bit about her work in trying to build new exhibits for the African American History and Culture Museum, which will look to open up soon. Many of the exhibits in the museum were built to be interactive and touch capable. With the COVID-19 pandemic, they need to revisit their approach, finding ways to avoid having visitors touch shared surfaces.

There was an article after the webinar that included a bit more information. The idea for the immediate future was to use a visitor’s mobile device with QR codes or Augmented Reality apps that engage and excite people. It’s a great challenge, and as Ravyn notes, it’s an exciting time for DevOps and developers.

I think that’s one of the things that DevOps is supposed to produce. Some experimentation, and along with it, the excitement that comes from meeting and conquering challenges. Rather than big projects, we try smaller things, and adapt as they work, or don’t.

DevOps is helping many organizations reinvent how they perform software development. Many of the techniques are the ones some of us have been using for years, but the focus on the term has helped lots of managers rethink their processes. I’d urge you to look at DevOps ideas, but be sure you include the database. It’s an important part of the DevOps process.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.