As a software engineer you produce changes. They could be in the form of code enhancements, bug fixes, configuration changes etc. The rate in which those changes are implemented is the driving force behind most "DevOps" and "IT Transformation" initiatives. There are tools and practices that will help improve the rate in which changes are deployed, but there is a culture shift that also must happen in order for these initiatives to be successful. A change in mindset must occur to realize that changes are a good thing. Let's explore how we got here and how "The Three Ways" DevOps principals can be applied to achieve this new mindset.
Why are we so afraid to change things?
Most organizations have a long history of installations that have gone wrong. The IT community is full of stories that sound like old boat captains telling a tale of the rough seas. Most organizations have installation windows that are typically scheduled during their "off-peak" times. If something goes wrong there is usually a fairly detailed roll-back plan and there is a certain time during the window that a "go no-go" decision is made to implement that plan. There has been a long history of anxiety around these change windows and I am pretty sure most of us have had our hands slapped at one time or another for a change that didn't go as planned. This fear of failure has led us down the road of very complex and infrequent off-peak deployments. If people start to fear making changes instead of getting rewarded for them they are going to make less changes. "We should probably refactor this, but we never will" or "The last time someone tried to change that code it broke five other things so we don't touch it".
Code freezes are not a good thing
If you have worked in IT or software development long enough you have asked the question, "When is the freeze over?". Code freezes
typically happen in the financial sector at the end of the year and in retail around the holiday season. These freezes make everyone feel better about their stability because nothing is changing (except for that super important thing that got sign off from three levels of directors). It has been my experience that code freezes are never really freezes. They usually just start to rank changes as important changes or really really important changes. What people think they gain in stability they actually lose in the in-stability of the next release after the freeze is lifted because in most cases all of the work that has been piling up during the freeze is really difficult to merge, install and test.
The first way - "Work flows in one direction"
This can also be thought of as "always fail forward". The faster changes can be installed the faster things can be fixed. This means that instead of spending the time to execute a back-out plan you can implement the fix that allows the original installation to remain in place. I am not saying this is a hard and fast rule. There are always going to be extreme cases that call for a back-out of the install. However, those should be extreme cases and the new normal should be to "fail forward". This will lead to shorter, or the elimination of, freeze periods. No matter how well you test and verify your changes there is always going to be the scenario or functionality thing that gets missed until it hits production. Understanding and accepting that those problems are not the end of the world is a big step because you can quickly remedy the situation.
The second way - "Shorten and amplify feedback loops"
We all would love for changes to be able to be implemented quickly and with a high level of confidence. To achieve this the installation steps should be able to be tested before they are performed in a production level environment. With cool tools that allow for configuration as code, installations can be scripted and are repeatable. You will also know very quickly if something has not gone according to plan. Installing changes more frequently leads to people getting really good at it. Getting good at it boosts confidence. Confidence leads to doing installations more frequently. See where this is going?
The third way - "Foster a culture of experimentation and risk-taking"
Making changes faster is a good thing. It leads to confidence and less down-time. We need to get out of a mind-set of fear and think of implementing changes as exciting and rewarding. People will be more willing to try new things. I like to think of it as going on offense instead of always being on defense. If all you are ever doing is fixing defects from the previous release then you are really never going forward as fast as you could be.
Conclusion
Don't be afraid to make changes. If you are then ask yourself why. Those reasons should be the things that need looked at as opportunities to improve. Changing things is good. It is what they pay us all of that money to do.
Top comments (0)