Code Governance: Do you have one?
Let's remove some dust of this blog.
Lately I have read the Site Reliability Engineering Google Book in a Book Club at my not that new job at Pagar.me.
The Google book is about process. A step-by-step recipe tested and stressed by Google over the years when everything was being learned on the fly and AWS didn't existed to make our life less miserable while operating our systems.
As a Software Engineer, I have learned in the past few years about all the layers that a product development needs: Architecture, Design, Deploy, Operation and Coding.
With that background, I became a fan of automation: If it can be automated, it will be on my watch, and with this recent discussion about the process that Google tell us in the book, I can see what is the value and quality of life that we will have if we adopt some of those processes to our daily coding life.
And this is why I'm writing about Code Governance. We have Corporative Governance, ITIL, ISO normative's, and a lot more. But I see few contents on how to make your code compliant to company standards while coding on your machine.
I'm tired to suffer about the same problems, over and over, in different companies and different projects. We leave technical debts that are never paid, almost no documentation, and wells of knowledge in a few people that when they leave the project or company, when a difficulty appears, hell is installed.
So, if I can make my lifer better with automated processes, tying what I can to automation tools, I'll do. Because for me a developer must worry about the big picture, not only on the PR that it's opening. You don't need to know all the technologies and frameworks, but you need to be capable to understand how your job impact the life of everyone in the chain of responsibility of the product/application that you are working on.
First we need to change our mindset, for that we need to read, study and debate. Then we can try to change the Company Culture, which is a lot harder, but not impossible.
What is on my control? The tools that I can attach to the code development process using pre-commit, CI/CD tools like GitHub Actions and GitLab CI, and the evangelization that I can do in my team and others about why this is important, and why everyone needs to worry and demand that this process is followed by everyone.
This is why I think that a Definition of Done is also important. With that process defined, we know what checkboxes do we need to say that an Epic is Done, and evolve that process over time. It's hard to create a process, and in first sight can be scary to see the amount of things that we are leaving behind because we don't know, or we choose to not worry and just expect the day that everything will blow. And trust me: That day arrives, and the damage can be big.
Our code needs testing, but why test only in the CI? Why encumber our CI with push after push because the tests, lint and other steps are breaking? Why I need to ask people to follow PEP8 on each PR that I review? I can tie tools to the project that only let the developer push to a remote repository when a lot of standards that are tied to code are meet. And with that, I can review a PR faster, save money on CI time, and deliver more value in each task that I close on Jira.
Because, automation, CI/CD, patterns and VS Code extensions exists for us to deliver more value, and not waste time in fixing a PEP8 rule in our code.
I know that defining and following processes are kinda boring. On a first look, they may block us of delivering work and sound just like more bureaucracy is being added to our lives. However, if there's a good thing about working in tech, is use the Agile method of always evaluating and improve the process to fit into our reality, and not invent excuses to not follow the governance process.
Governance will deliver its value in the long run and make us miserable in the short. It will not be tomorrow, neither next week, but that also highlights the measurement tools that we need to use to see if the governance that we defined are delivering the expected results.
With that said, as much as I would like to tie all the compliance checkboxes to automation tools, sadly I don't have that kind of power when we talk about Documentation. And IMHO, documentation is tied to Code Governance. And for me, that is the biggest challenge that we need to face to make our lives easier and less miserable. Because we ship the code, and the code is there to haunt us to do maintenance and operate. And if we have none too few documentation, you will waste precious time in the investigation, in the middle of an incident where you need to remember your logic of a code that you didn't have touched in the last 4-5 years. And then you will want to slap your past self for not doing the documentation and maybe testing that would make you less miserable right now.
That's all folks.