DRMacIver's Notebook
Defects are the responsibility of programmers
Defects are the responsibility of programmers
This post is an elaboration on a Twitter thread about software I did yesterday.
Hillel wrote Defects are not the fault of programmers. It is a good post and I encourage you to read it.
In particular:
No, the bigger issue with “programmers create defects” is an essential issue with the worldview. Its basis in facts is less important than its value as a “lens” we can use to understand defects. If we know where defects come from, we know what we need to do to manage them. To emphasize this: Our worldview on defects shapes our means of reducing defects. We measure the value of a lens by how useful it is.
So what does the “defects are the fault of programmers” worldview tell us about our means? It says that the only way to reduce defects is to improve programmer discipline. Either the programmer is sufficiently disciplined and nothing can cause defects, or the programmer is insufficiently disciplined and nothing can prevent defects.
I’d like to argue that Hillel is mostly correct, but bugs should also be considered the fault of the programmers.
I’d also like to argue that the idea that bugs are the fault of the programmer, as implemented in practice, is in fact much worse than Hillel is making it out to be. The worst part of “defects are the fault of the programmer” is not that it doesn’t help us to reduce defects, but that in fact that over time it virtually guarantees to increase them.
A software development process is not just there to produce software, it’s also there to produce a software development team, and in order to understand the effect of any given process you need to consider its effect on both. Systems which have positive effects on the software while having negative effects on the team, will, in the long run (which often is not that long - a year or two if often more than enough) end up backfiring horribly on the software as well.
In particular, defects are a normal part of the software development process. People make mistakes, people misunderstand things. If you’ve never had a bug in production then that’s probably because nobody is using your software or you spend far too long developing it.
So independently of the question of whose fault a defect is, the more important question is: When a defect occurs, does your software development team get better or worse?
I’d like to suggest that any system that relies solely on personal responsibility will get worse in response to bugs, but so will any system that treats bugs as not the programmer’s fault.
Ideally we want people to take responsibility for shipping high quality software. The basic problem is:
- If people don’t care about getting good results, there is no system that will get good results.
- If people do care about getting good results, basically every system works well.
- The system you choose determines which of these scenarios are stable states.
In particular if a system relies on people caring about getting good results, in the absence of support for that, you will burn out the people who care the most, they will stop caring and/or leave, and you will end up with a team that doesn’t care about getting good results.
One of the easiest ways to create this dynamic is to have a culture of personal responsibility for defects while pressuring people to ship, and providing no collective support for what to do in the event of failure. If you treat “defects are the programmer’s fault” as your guiding correctness principle, you will end up with a team whose response to that is “Yeah, but who cares?”.
But also if you treat defects as intrinsically not the programmer’s fault, you do this. “Human error” is a bad attribution in that you can always find a human to blame, but “System error” is also a bad attribution because you can always find a system to blame. Humans in the system are what create performance as well as defects, and if you treat humans as never the problem, what you end up with is safety clutter where people’s hands are tied. And, once again, people will tend to get frustrated ane leave. They won’t necessarily be the same people as left in the other scenario, but having a team full of people who are entirely comfortable with plodding bureaucratic slowness at every step of the way is also not a great end state. A key part of getting good results is that you have to get results.
I would suggest that a crucial part of getting to a system that creates a good team is that guilt. When something goes wrong, the person responsible should feel appropriately guilty.
The problem with this is that we are all very bad at guilt.
Yes, I can hear you thinking “Oh don’t worry David, I’m very good at guilt”. That is exactly the problem I am talking about.
Being good at guilt doesn’t mean feeling a lot of guilt. It means feeling an appropriate amount of guilt, which can range from “Oops, my bad” to “Yeah that was a massive fuck up on my part. I’ll make it right”.
The problem we collectively have with guilt, both in terms of how we experience it and how we inflict it on others, is that we treat it as a binary with very little between no guilt and massive irredeemable shame. This is intrinsically unhealthy. Guilt, properly handled, is an acknowledgement that you have done badly and an impetus to do better. It cannot serve that function as we currently manage it.
The second crucial part of getting to a system that creates a good team is that “I’ll make it right” part. If people feel guilty but are not empowered to fix it, then you once again end up in the situation where everyone who cares burns out and/or leaves.
Sometimes that empowerment to make it right will consist of the programmer, as an individual, resolving and learning to do better. Sometimes it will be about changing the system. Sometimes they’ll be able to manage it on their own, sometimes they’ll need support.
There is, sadly, no universal prescription that works. The world is messy and complicated. But if you give people the support they need to do better, and create a system that tends to improve rather than degrade the moral, emotional, and professional skills of its members, and responds healthily to the normal trials and tribulations that the world has to throw at it, it will probably go pretty well for you.