Tag: DevOps

I love this quote from Randolph West: ” Listen to people. Have strong opinions, but loosely held. If you are wrong, admit it and move on. Learn from those around you.”

This is from his blog on diversity, which I support and agree with. He has some great thoughts and the post is worth reading. Maybe you appreciate diversity, maybe you don’t, maybe advocate for or against it, but in all those cases, I think his message is worth reading.

I am not going to talk about minorities or ethnic groups here, but rather diversity of thought. That first quote could apply to software development in general, and certainly the idea of a DevOps process for building applications. It’s good to have strong opinions, and good to be able to debate and argue them, but it’s also good to keep those strong opinions loose. Many of us find as we get older and more experienced that we often have a huge gap in the things we don’t know that we don’t know.

These are the unknown unknowns, as opposed to the known unknowns, which are things I know I don’t really understand. I’ve remarked to a few people that learn new things every week, and I feel stupider every week. Why? I learn things I never knew existed, so I constantly expand the knowledge of my own ignorance. It feels like I learn two things and then realize there are nine more new things I don’t know anything about.

Today’s software requires a team. Maybe more importantly, today’s software requires a team of both application and database developers, as well as infrastructure staff, that can help put together an entire system. We need to work together, not independently with hopes of efficient integration of our ideas later. We want to shift left, and coordinate and communicate earlier. That needs strong opinions on how to best do a job, but a loose grasp on those as we might need to adapt to work with others.

Read Randolph’s blog twice. Once thinking about the topic of human rights, and then once more thinking about teams and our opinions on building software. It’s thought provoking and worth a few minutes of your time.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

The hardest part of transforming to a lean, efficient process is the culture change necessary to get a team to work together. It doesn’t matter if the team builds software or vehicles, the change to working in a new way, into disclosing problems, admitting issues, working without blame to fix them, these are very, very difficult changes to make.

Dr. Edward Deming and his work with the Japanese have been the source of many ideas on how to improve a manufacturing process and increase quality. The ideas and principles are incorporated into The Goal, a novel that inspired The Phoenix Project. I recommend both those books for people interested in DevOps because building software is very similar to the manufacturing process used for other goods.

Toyota has been one of the leaders of quality manufacturing and the Toyota Production System has been used as a model and adapted by many industries, including software. One of the ideas used in manufacturing is the ability of anyone to highlight potential problems. In car plants, this has been implemented with an andon cord, a way to stop production and have others help diagnose and solve a problem early in the process.

Some have thought this is a culture issue where the Japanese might be more willing to highlight problems and work as a team, something that many Westerners have struggled to do. At the lean blog, they talk about how this isn’t the case. In fact, the Japanese, in general, seek harmony and might be less likely to raise potential issues. In fact, I think most workers are hesitant to raise potential issues, for a variety of reasons. Often anything that slows down work is frowned upon by management, which often leads to issues lingering on, or substandard products being produced. This also happens in software.

I might argue that changing culture for developers is hard, but even harder for managers. We often don’t train managers well, and certainly we don’t often have good systems for coordinating work between and among knowledge workers. The systems that help with manufacturing give us a base, but they don’t apply quite the same way when your “machinery” is another human. Culture change for DevOps must include management and that means less oversight and interruptions, blameless reviews, and embracing mistakes and small failures. Those are often very hard for managers but necessary if you want to improve your software.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.