In a perfect world, when we release something to production everything works smoothly and goes according to plan. We don’t live in such a world. There are a lot of people who believe that if they can fix something fast in production they can release immediately. When something breaks we release a patch or roll back the change. Now this does sound great in theory..”we move fast”, “we ship multiple times a day and wait for no one”, but we need to ensure a couple things along the way first.
When we work this way, it may be fine when our user base is not very large or the feature only affects a small group of people. Where it gets dangerous is when we don’t realize our user base has grown. If we roll out a feature to 10% of our users, that could’ve meant 100 users 3 years ago, but today that could mean 10 000 users. We get so accustomed to this mentality we never realize the impact of our changes until something catastrophic happens.
What about forming bad habits and not improving our critical thinking skills? When all we think about is the implementation and ship as soon as we are ‘done’, we lose that critical thinking aspect where we analyze scalability, performance, security, and so on. We don’t think about how our code could break before we ship. We become just mediocre software engineers who can push out a feature just like anybody else. Everyone can code. What makes people stand out is all the extra stuff, the stuff that takes time and adds a ‘wow’ factor.
Another thing we need to understand is the process could be very different at other organizations. What if our code quality is not up to the standards of the organization? Developing good habits continuously can mean your skills are transferable.
Now, if we have a large set of automated tests, an excellent beta program, a great plan for how we are going to handle a fire, then perhaps for the time being we can continue our ways and are willing to accept the consequences. It’s essential that we assess the above over time and make changes where appropriate.