Diverting Blame Effectively in Software Development

I previously blogged on how to effectively sweep problems under the rug in Java, but even with the tactics discussed in that post, it's not always possible to hide every problem encountered when developing software. In this post, I look at tactics software developers can use to avoid direct blame for problems and issues that cannot be hidden or easily fixed.

Dealing with Version Control Tools

Version control (AKA source control) offers several advantages, but can also be one of the easiest ways for others to know when you've introduced a particular bug or issue. One option that seems to not be used much anymore is to avoid version control systems altogether. Without version control, it isn't as easy for someone else to find out who delivered a particular line or lines of code.

Even with some sort of version control in place, there are tactics to reduce the ability of others to see when you've introduced a bad piece of code or made a change with negative repercussions. One tactic is to convince a fellow developer to merge your changeset for you. Depending on the version control system you're using, this is accomplished in different ways, but at a high-level typically involves you supplying a patch of your changes and asking the fellow develop to merge that patch's changes into the main development branch.

Because it's often not easy to get someone else to merge for you or to otherwise prevent the version control system from showing you as the responsible individual for code changes, an easier tactic is to put things in the version control commit or merge comments that deflect blame. These comments might ascribe the change to someone else. The comment could say something about merging someone else's changes for them or that the changes were someone else's idea and imply that you merely made the requested changes for them.

The problem with referencing other developers in version control delivery comments is that, in many version control systems, these developers will see the delivery comments as the deliveries are being made. In such cases, it's often better, if possible with your version control system's configuration, to change the comment AFTER the delivery has been made and AFTER any automatic notices of the delivery have been issued.

In-code Comments

In-code comments can be a great way to divert blame. A well-written comment can be convincing and might even preclude a fellow developer from bothering to use the version control system history to see who made a change if that developer sees an in-code comment explaining the change or addition. These in-code comments might state things like, "This was Frank's idea" or "Change made at Anna's request." If mentioning specific names is too risky, the comments can be more vague as to whose ideas are implemented ("I was directed to do this because ...").

A specialized form of an in-code command that can be particularly useful in deflecting blame is the infamous "TODO" comment. This "TODO" comment can be used to make your problem someone else's future problem. This approach is particularly effective if the current problem is described in this comment in such a way that it seems impossible to address it now and so it must be addressed at some point in the future. One might even go further and pretend it's someone else's "TODO" by placing the other person's initials in the comment or referencing the other individual. There might even be an implication that the other individual will be or should be the one to resolve the issue.

Apply Logical Fallacies

There are numerous logical fallacies that can be applied in response to others' critical code reviews or other mentions of problems with your code. One that can be effective is an "appeal to ridicule" in which you make it obvious that you won't waste time on such an absurd argument; this works best when you are the more experienced developer or are in a higher or more powerful position. Sometimes, to pull this off, you might need to imply that the other person will some day understand.

The "false authority" logical fallacy is also effective; with this one, you just need to find one person who makes an argument for doing something the way you did it and then cite that is THE authority. You want the person writing this to seem as credible as possible for this to work well. Alternatively, one could use "false attribution" to quote someone well-credentialed authority in favor of one's position without actually citing the source (because there isn't any).

One particularly effective approach can be to respond to critiques with comments quoted by authorities out of context. One of the most obvious here is to defend one's poor code choices with the argument that one was simply avoiding premature optimization.

Muddy the Waters

There are several tactics one can use to "muddy the waters" to make it difficult to ascertain who did what when. Some examples include mixing substantial changes with refactorings and cosmetic changes in single change sets, breaking an otherwise cohesive set of changes into multiple merges over time to make it difficult to see when the issue was introduced, making changes in files with lots of changes so that others' merges show up over your own merges, etc.

Write Unit Tests that "Prove" Your Code Works

Unit tests can be very useful for a variety of reasons, but they can also be the first to expose your issues. Fortunately, you can make unit tests work for you when covering up your issues by writing tests that assert your incorrect code is fine. Then, when someone finds an issue with your code, you can blame the unit test for being at fault.

Blame External Forces

When it's not possible or ill advised to blame another developer, blaming inanimate items that won't attempt to defend themselves can be effective. This approach is most effective when the blame is directed at items that are already viewed with disdain by those around you and include things such as tools (IDE, version control, static analysis tools, unit test frameworks, etc.), schedules (including deadlines), libraries and APIs, existing code, the environment ("it worked on my machine"), etc.

Management and/or customers can often be blamed to at least partially deflect attention. Being outraged at the ridiculous requests or unrealistic requests of clients and/or management can lead to empathy and agreement from fellow developers.

Divert Blame to Code Reviewers and/or Test Organization

When all else fails, blame can be diverted to code reviewers. When problems are found during a code review, you can state that you placed them there intentionally to test the quality of the reviews and see if anyone was actually reviewing. When issues are found after the code reviews, you can blame the reviewers for not finding the issues during their review. If you have a separate test organization, the same tactics can be applied; you can say your problem was intentionally added to verify the testers were doing their job if found by Test or can blame Test for not finding the issues if they arise after testing.

Conclusion

This post has quickly looked at some of the tactics that a software developer may find useful when diverting blame.

By the way, Happy April Fools Day!