Does the Rogue Developer Really Exist?

We've all seen the movies or read the books, where a wicked-cool computer programmer goes rogue and changes the code for some reason. Hollywood's glamorization of how we program often makes our jobs look way cooler than reality, too. The technological wonder uses coding skills and knowledge to circumvent processes put into place for the protection of the corporation, it's assets, etc. Typically, in these storylines, the programmatic changes made save some aspect of the world in the process. The question is, does this person or situation really exist in the real world?

Frustrations from Standards and Practices

I was working for a Fortune 500 company when Sarbanes-Oxley (SOx) went into effect. As an Information Technology resource, I was expected to quickly get up to speed on the technology aspects of being SOx-compliant. One of the biggest challenges that existed at that time was that developers had access to production or had the ability to push changes into production environments. SOx presented the idea of separation of duties so that the person writing code isn't the same person pushing the code into production.

When I take a step back, this idea seems to have stemmed from accounting practices. When I think about the Big Eight, to Big Six, to Big Five, to Big Whatever accounting firms that were leading the SOx effort, I am not surprised this practice was inherited by Information Technology. On paper, it just made sense and was an easy translation that made executives (or the powers that be) happy. However, this concept led to frustrations when trying to fit everything into this same (very small) box.

As an example, I might have a simple service that is a tool to assist other development teams. While the function of the tool has nothing to do with the core business or interact with any proprietary data, it provides value to the teams and reduces a great deal of duplicate work. I can write the code and use a Pull Request (PR) process to have my changes reviewed and approved by other developers. From there, I can use my favorite CI/CD tool to push the code into the non-Production environments before pushing the button to update the Production instances. However, according to SOx compliance, I need to reach out to another person to actually push the button for the code to be deployed.

The Reality

In this implementation, I feel like the process is protecting against a rogue developer (or situation) that doesn't exist. So, we are putting in safeguards to handle that < 1% chance that someone is going to do something unethical. This is in contrast to most Information Technology teams who attempt to handle 80% of the needs first, then focus on the next 20% as it makes sense to the corporation.

Of course, people make mistakes, but those mistakes should be caught in the PR process, or in the deployment to a non-Production environment. If I had a guy in Dev Ops pushing the button to deploy code into Production, that individual is going to just push the button ... not look into the code first. That is the reality I still see today. Sometimes, the button pusher is someone who does not have the ability to comprehend the code being deployed.

So, we are back to protecting against that rogue developer, who in my 25+ years of experience in Information Technology has never existed. I mean, think about it, the risk imposed for going rogue far outweighs the reward that can be gained from such an effort. This would include time behind bars, plus losing all credibility in a technology world connected heavily by social media.

Conclusion

My goal here is not really to take on policies that impose the separation of duties within Information Technology. My goal is to think about what is being asked and what is truly being protected with such policies. On paper, in a boardroom, or in front of a symposium of congressmen, this may make sense. However, the reality doesn't seem to match the expectations. At least, in my view.

Have a really great day!