One of the biggest challenges to becoming better at building, deploying, and operating software is the culture changes required. DevOps requires we work as a team, which can be hard to do. Often people have competing interests and goals. They don’t trust each other as much as we’d like, and maybe more importantly, management doesn’t trust the people doing the work.
There is plenty of blame thrown around when things don’t work as expected (or aren’t delivered). That’s a poor culture in which to be creative or experimental. In reality, those things are a lot of what we do in software development. We aren’t solving the same problem over and over, building a bridge or house that is mostly constructed as many others are. Instead, we are assembling more complex systems in different ways.
Most of us aren’t building airplanes, but the situations and problems in this article could easily be applied to many software development projects. Ambitious sales, targets set by management, not engineers. A lack of listening to feedback and unstated pressures to just push things through the system, regardless of potential issues. Perhaps the only thing I agree with from Boeing’s side is that they can’t find all defects, just like we can’t find all bugs. However, we can often find many and minimize or eliminate the impact of the critical ones.
The pressure on Boeing engineers and line workers is similar to those in software, both on developers and operations. Development needs to deliver features, whether well-tested or not. Operations need to get these out, regardless of the impact on the system. It’s a gross generalization, but one repeated over and over in a few places I’ve worked.
Culture is critical. Part of DevOps is frequent deployments from a faster speed of deployment. However, that’s only one part. The other is that we continually learn and improve how we do things. We raise the bar of quality. If we are only focused on moving forward without getting better, we get into the position that Boeing was in. No trust, no psychological safety, and no attempt by management to implement DevOps culture. Instead, they’re just pushing for more features with (hopefully) more automated testing, but no real impetus to ensure this is the case.
More and more of the world is run by software. Whether this is in cars, restaurants, or government. When software doesn’t work well, there can be substantial problems that not only impact a bottom line, but can prevent people from getting goods or services they depend on. I know many of you that build and operate software try to do a good job, and I hope you know this means polishing your craft and improving your abilities. I also hope that management will learn that their support in improving quality is as important as the drive for more features in software.
Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.
Bad software can be just as deadly as a bad plane. Just about every medical device has code in some form. A poorly constructed OS or driver for some medical device critical to life support could be devastating. You’re correct in that you can never find it all so you have to decide on what is “good enough” and then stick to it. From that article I got the impression that Boeing management decided to increase production at the cost of safety and almost certainly because doing so would award one or more higher ups some bonus $$.
I’m certain that people with bonuses at United influenced things. Which is sad, and also how the world works.