Diffusion Of Responsibility

I’ve talked about ownership before. I’ve even mentioned diffusion of responsibility a couple of times. But I haven’t really talked about it. It’s time to talk about it.

I’m a grandfather now. Have been for almost a year. It’s amazing watching my granddaughter grow and learn. It’s also mazing watching my daughter learn about being a parent, just like I did many years ago. Unsurprisingly, we have many of the same opinions on how to raise a child, but it’s about 30 years later, so we’ve all learned a few things and advice has changed. If nothing else, car seats have changed a lot. The car seats we used back in the day weighed a lot less than the baby. The infant one my granddaughter used weighed more than she did.

Some things haven’t changed though. You need to watch toddlers all the time. They’re curious, and they’re fast. One thing my daughter is doing that is a really good idea is that when they’re out and about with she’s out and about with her daughter and friends, especially near water, the baby has a dedicated watcher. Everyone is thinking about her, and will act if they see a problem, but someone has the responsibility. Because diffusion of responsibility is a thing. If everyone is watching, then no one is watching.

Obviously, it’s not a binary thing. But if you know that everyone is watching, you allow yourself to get distracted. You don’t force yourself to pay attention when there’s something else pulling at you. Because you know others are watching, and they’ll notice if something happens and do something. Right? Probably, but not certainly. They might be thinking the same thing. Counting on someone else to be paying close attention.

The same thing applies to software design and development. Particularly to the non-functional requirements(NFRs). Everyone is responsible for them, in all parts of the software development lifecycle. When you’re developing a new feature or fixing a defect/bug/regression, you know that’s what you’re trying to do, so you focus on that. That does not mean, however, that you stop being responsible for the NFRs. You’re always responsible for them. And so is everyone else.

The thing is, software development is a socio-technical activity, and as we’ve seen, with us humans, the default is that if everyone is responsible, no one is. That means we need to be on guard for that bias, and work to ensure that it doesn’t let us get into bad habits.

There are some simple things you can do that can help. When you’re designing that new feature of fixing that defect, think about the future. Think about not just the specific problem, but the general class of problems. Can you make some potential issues impossible with your design? Like everything else, the answer to the question of “How much abstraction should I add here?” is “It Depends”. If you’ve been asked for a code review, either do it well and truly, or decline. You do your part by either doing the work or making it clear that someone else needs to do it. If you’re sending code out for review, review it yourself. Take the time to look at it with fresh eyes as someone else would look at it.

There are organization things you can do. Maintaining code quality is everyone’s responsibility, but you can have a team whose job is to make sure that people are doing that. That’s what my team at work does. We don’t add the quality. We don’t schedule the tasks to add quality. But we do look at things from a quality perspective. We let folks know where they’ve missed the mark, and we provide tools and training to help them do better.

Ownership and responsibility are important. Everyone can’t be responsible for everything, or nothing would get done. But that doesn’t mean that no one is responsible for some things. Some things are everyone’s responsibility.

It’s just that sometimes we need to be reminded that there are some things everyone is responsible for. And everyone needs to do. Those things are often called Norms. And that’s a discussion for another day.