There is one analogy that relates to my experience of software development that I like, and I like to bring up, again and again: the dishwasher in a shared space. Any shared space, any dishwasher, it’s always a mess. Take the kitchen at work. You say, “it doesn’t really matter”, I say “it is so simple to keep it tidy”. I liken it to software development. Even when we start with the best of intentions and great code, it gets messed up, quickly. Like the first person putting their stuff on the rack, and those who follow, at some point it becomes a wreck. A sort of tragedy of the commons1.
So why is this such a good analogy and how is it illuminating? Most of us work with smart people, yet we seemingly cannot manage the simplest of shared activity, keeping the dishwasher functional. Why is that? We clearly have the brain power to tell a bad arrangement from a good one; Do we not? We can see, that filled to the brink, it does not perform well; Can we not? Is it because we don’t notice? Is it because… it’s not a priority (we don’t care about that particular thing, at the last minute, heading out the office to catch a bus, or we’re distracted by some other thing)? Is it because we’re not the ones doing the clean up (not my problem)? We don’t see the consequences so we don’t identify the cause. Is it because you think I don’t care, because I think you don’t care, because we might not notice each others good will? We chuck it in, run out, and the one person that cared enough to sort it out and write to everyone won’t be doing it for long. They’re not stupid.
It might be some of those, it might be all of those, either way software development is the same. We tend to think that software is complex2, and that’s why quality deteriorates quickly, but to me it looks like it is actually something else. An emergent phenomenon, be it a simple or complex task, as long as it is a shared activity. Technical competency, it seems, is not the only thing that counts.
I’ve observed and experienced more diffusion of responsibility than I’ve seen distribution of responsibility (it takes a lot to step up). That is how it seems to work. It is not necessarily conscious, though the effort to fix it is. Team-work can be hard, even a committed two-person team (as soon as it’s more than one person), to get it all right all the time. You essentially have a split brain. You forget to communicate this or that. You are not in synch. You make assumptions your peers cannot make. You have priors your peers cannot possibly have. It is mutual. Normally there is more than two of you. Things start to go a little wrong. You notice. You take corrective action.
To what extent? Enough to fix that one instance or for all time? Should you have done it sooner? Probably, but better late than never. You see, that is because we must identify these issues largely alone, but fix them as a team. Systematically crossing these boundaries, from a single instance, to dealing with it, is a difficult transition to make.
I think the analogy not only helps understand the state of software but can also help fix it. How far can we take it and how deeply analogous are any fixes? I had a colleague who explained that quality was a matter of process: quality in an artifact is because of quality in the process 3.