Code to get around the process OR Code it right and improve your deployment methodology and the process

Code is just code. Process is just process. However, when you combine the two, they impact each other in ways that they should not.

Let’s assume you built a platform for your team. Then the process came later and slowed down things but kept things as stable as possible. Then software engineers realized that they can follow the process and do the development in such a way that they can go quicker through this process. I am talking about writing code that is so over-configured that it actually allows you to deploy changes to production quicker just because it is a configuration change that you are deploying. When your platform is over-configured, the weight of a configuration change is so huge that you can introduce functional changes to the degree that makes you wonder if you are adding so much risk to the business because you are taking a shorter path in the process workflow. The risk is there because software engineers don’t feel comfortable making these heavy-weight configuration changes and nobody likes doing any change in the engine of the code that drive this heavy configuration.

This really smells as coding to get around the process. Is this right?

I am all about automating the process, but when it comes to over-configuring your code just for the purposes of getting around or going quickly through the process, it is totally wrong.

As a software engineer or a technical lead, every time you find yourself thinking how to adjust the code to make it very configurable to get around the process, you should ask yourself the following questions:

• How can I help automate or implement the continuous integration in such a way that I can do the right thing in my code. The right thing could be that you actually make a code change that requires a compilation, build and deploy and the code instead of trying to make it configurable and complicating your codebase and increasing maintenance costs.
• How can I work with the Change Control team and improve the SDLC/PDLC process in order to make it jive with the platform/framework you have implemented in your company.

It is ok to have a simple code change instead overcomplicating the code to make it configurable so that you change ends up being a configuration setting.

In conclusion, it is important that you design your process at the same time you are building your new platform. That’s how they compliment each other better. As for software engineers, please don’t code to get around the process. Please code it right and identify incremental changes how you can improve your software deployment approach.

Thank you for reading. Please follow me here on Medium.com or check out my personal blog: http://www.almirsCorner.com

Almir Mustafic