In one of our sprints I had worked with another developer to fix a bug that we found in one of the modules already implemented and integrated into the Main codeline. The bug must have been there from the start and it accidentally deleted an attachment from the database if it was considered too big to be handled by the UI. It was fairly easy to miss, although not exactly a minor bug. You just had to stumble over it at some point and we did.
During the sprint demo we mentioned this bug while going through the list of important bugs we fixed and it quickly turned into an argument with another developer from a different sprint team about whether this really was happening (it was, data was deleted from the database, we CHECKED), whether it had any side effects (it did, only those were the same side effects that had already been there from the start) and when this bug was introduced (guess what, nobody cared, it was a bug, it was fixed, end of story). The quote that stood out though was the overly awesome „Then it was not my code.“
So here’s the thing. Nobody cared. So far nobody had blamed anyone. Nobody had checked source control to see who was to blame, because so far nobody had thought about checking. Once we had found the reason why data was deleted we started working on a solution to not let that happen. Then we closed the case.
Naturally after the sprint demo the first thing to do was to actually check who introduced the bug. I don’t need to tell you, who it was, do I? On the plus side, from that day „Not my code“ became one of the most quoted lines in our office.
Here’s the thing. In our development department there was a lot of healthy blame going round. By healthy blame I mean the kind of blame where you find something wrong or strange in the code and you go to the person who wrote it and ask about it. It’s the blame where when a feature goes wrong you go and have a talk about why it happened. It’s the kind of blame where when you find awkward code you sit down with the developer who wrote it and go through the code.
To sum it up: You might name names, you find the responsible person, you point out the error. But you do it because you want to improve the team, the code and the process. This is not about telling someone that they are stupid or pointing fingers and feeling superior. The fact was, everybody was doing it all the time.
Yes, even this kind of healthy blame might feel bad sometime. It’s not your favorite moment of the day when someone stands at your desk telling you that you probably did something wrong. It’s also not your favorite moment when you have to go to someone and point out a bug that you found.
Here’s the thing: It’s not personal. It made people aware of when they didn’t understand a concept. You would sit together and figure out what the issue was and how it could be solved. It made you re-evaluate how you went about implementing something and probably made you vow not to do it again.
Basically, healthy blame can be relabeled as „learn from your mistakes“. The only thing is that in order to learn from your mistakes someone actually has to come up to you and tell you. Otherwise it simply won’t happen. So embrace the blame. And as the blamer be prepared to be proven wrong. It happens all the time as well. That piece of weird code might actually have a reason – it just needs better comments.
What this has to do with „not my code“ is very simple. In an environment where blame is not considered evil, you don’t care about who did what and when. If it’s something serious or discussion-worthy you will seek out the person responsible. If it’s nothing serious, and easily-missed bug, some inconsistency or some code lines that aren’t exactly pretty, you just fix it, be done with it and move on the next thing. And that’s what we did.