Human factors

An issue which I always find depressing but sadly unsurprising in discussions of process with software is the frequent disregard for human elements; indeed often the goal people have in creating process is to try to control and eliminate human elements. Little thought is given to what is going to motivate people to do what’s asked and if they are going to follow it at all, or in the spirit it was intended.

One example I’ve seen several times is the idea that some engineers work on irrelevant things and that this can be fixed by requiring every commit to be tied to the project plan or a bug so off project work is obvious. This isn’t really attacking the problem so much as putting a roadblock in place to try to avert it; the real problem is normally people not communicating about what they’re doing and what’s important but those problems are really hard to address. Sadly what tends to happen is that people work around the roadblock and cause some collateral damage; for example devaluing the bug tracker by referencing irrelevant bugs or creating meaningless bugs solely to allow commits, while continuing to behave like they did originally. This is often worse than the original situation.

This sort of issue is one of the things I appreciate most about working on Linux – there’s quite a bit of process but because of the way it has been evolved the incentives are usually right to make sure they are followed in the spirit in which they were intended. For example the patch submission process is essentially just best practices for making sure changes go to people who care in a form which makes it easy for them to work with it; there is a bunch of tooling around it which built on those practices (and in turn influenced the practices) but it all comes back to that basic thing of getting attention for changes and making them easy to work with. As a result people mostly do the right thing (or close enough) so everything runs smoothly. The trick is to remember to standardize and write things down when it’s needed – notice the good practice and spread its adoption.

The key difference here seems to be if process is viewed as something to solve problems for people or if it is viewed as a way to solve problems with people. If the problem is with the people then the view starts off negative and it’s perhaps unsurprising that there is little consideration of how they will react. Sometimes it’s not so much that a problem is seen with people as that the people doing don’t have any real interest in the process (write only timesheets often bear no relation to reality for example) but there is an assumption that they are going to just do what they’re asked (but instead they for example don’t fill in their time sheets or don’t provide accurate information). The end result is the same, their needs don’t get considered and their actions end up being counterproductive.

Starting to avoid these problems is fairly straightforward – take a step back and consider why the people expected to carry out the process are going to want to do so. How does it help them? How will they see it helping others? Generally what’s in it for them? If these are difficult questions to answer then there may be a problem – it is likely people will ignore the process or do it badly without a lot of active enforcement, but perhaps that’s OK for the situation. Beware of using metrics to provide incentives, metrics are gameable and that game can cause problems without care.

But do think about people; making software is all about people.