It’s possible that you have never written a bad line of code. Possible, but unlikely in the extreme.
The reality is that you, like every other developer on this planet, creates security flaws, misaligns UI elements, and more. It’s not that you’re a bad developer. You just happen to be human.
It’s this “all too human” weakness that each developer has that drives the best developers to assume the worst in their code and underlying infrastructure, and plan for it. Here’s what they do.
Assume Chaos
A few years back, Netflix open sourced Chaos Monkey and other parts of its Simian Army, a set of tools for managing cloud-based software. In essence, Chaos Monkey ranges throughout your Amazon Web Services infrastructure, randomly terminating instances. It’s basically a way of preparing for the worst by creating the worst possible scenarios.
As Netflix’s Cory Bennett and Ariel Tseitlin wrote on a blog at the time of release, “Failures happen and they inevitably happen when least desired or expected. If your application can’t tolerate an instance failure would you rather find out by being paged at 3 am or when you’re in the office and have had your morning coffee?”
By simulating failure in unpredictable ways, Netflix forces resiliency into its infrastructure. Rather than assume the best, it assumes the worst. As a consequence, we merrily watch old episodes of the Brady Bunch without a hitch.
The Best Coders Test
That’s a great way to improve one’s infrastructure, but what about code?
According to noted programmer Jeff Atwood, the answer isn’t too dissimilar: “Do terrible things to your code.” As he writes:
I believe a key turning point in every professional programmer’s working life is when you realize you are your own worst enemy, and the only way to mitigate that threat is to embrace it. Act like your own worst enemy. Break your UI. Break your code. Do terrible things to your software.
In practice, this means that “programmers need a good working knowledge of at least the common mistakes, the frequent cases that average programmers tend to miss, to work against.” It means your responsibility as the God of Programming is also to be the God of Testing, actively trying to root out errors in the code by “doing terrible things” to it.
Andre Medeiros adds to this, arguing that we should try to “get lean” with debugging just as developers increasingly do with their code.
“To prevent bugs, write code that looks easy in any programmer’s eyes. To fix bugs, understand your code. To understand your code with precision, enumerate and validate your assumptions, building debugging tools if necessary.”
Building Skyscraper Favelas In Code
Of course, one of the biggest problems with our code is that it inherits so much other code. Particularly within established enterprises, often we build on legacy code, creating all sorts of downstream problems.
Here’s how Zeynep Tufekci colorfully describes it:
Think of it as needing more space in your house, so you decide you want to build a second story. But the house was never built right to begin with, with no proper architectural planning, and you don’t really know which are the weight-bearing walls. You make your best guess, go up a floor and … cross your fingers. And then you do it again. That is how a lot of our older software systems that control crucial parts of infrastructure are run. This works for a while, but every new layer adds more vulnerability. We are building skyscraper favelas in code—in earthquake zones.
Obviously, there’s little that can be done to improve on this until we become committed to removing technical debt.
But perhaps, just perhaps, a willingness to do terrible things to our code will showcase just how critical the removal of that technical debt can be.