|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Make time for a friend and have a coffee, meal, or just spend time. I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
Psychological Safety 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. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
