Foreword

I am not an advocate of blame. blame here refers to - as some of you might have guessed - git blame. This topic has been discussed all over the internet (insert some articles about git blame and the power of git blame), but I have seen far too many projects, blameless. And for this reason, allow me to reiterate this in a blog post, in the hopes that someone might find their way here.

Painpoints in production code

Most people that have worked with software realized that at some point, code and practices are bound to be ancient relics. Especially in code that is not well maintained, a new person diving into production code will cringe, and as such reverts to the mentality of “if it ain’t broke, don’t fix it”.

There is some truth to that mentality, but it is one of those that are more ambiguous than cliché. This kind of approach in maintaining software will only lead to frustration in the long run. Say you see a code that does not belong. It might be a hack, a workaround, or whatever. Remove this line and your tests might be screaming at you with red markings immediately. Worse, remove that line and your tests still passed. Your mind now wanders, “is the test in this codebase proper?”, “what if a case is not covered in the test?”. OK, maybe trust that the engineers have had to properly write the code. But, are you willing to risk it and ship it? Your anxiety rose through the roof. You decide not to do anything with that particular piece of weird-looking code.

Or maybe you decided that it is alright to remove the line. Everything works well, and you relax for a while. Until a few weeks later, you have forgotten about it and someone got paged. You learned that removing these kinds of code is not worth it, and you will most likely in the future let this code fly by you.

Nah.

So, just have a higher standard for software developers/engineers.

Maybe. Maybe not. We, as a human (which I assume you are), will at some point make an error. Be it a bad day, sleepy eyes, or distraction, whatever it might be, I strongly believe that any human will make some error. It is a question of when.

So, just have someone review it. Even better, have more reviewers!

Statistically speaking, in an ideal world, we would like to have 100 reviewers. Even getting 5 is nice. But people are busy, and companies might be lacking resources.

A single reviewer simply might make the same error with the person implementing the change.

So, blame?

I’m pretty sure most of you by now had seen the use case of blame here: “Do a git blame and see why the code is there from the commit message”. Seems simple, but I have seen too many projects and organizations that simply forget or ignore this.

That is to say, it is not blame that one needs to practice. It is the practice of documenting all things that seems trivial. This can easily be done with commit messages. Other bigger explanations can be put into an internal documentation system. It might be easy for you at the time, but the next eyes looking at the code might disagree. Maybe the next person can find the reason on the internet, but why make their life harder?