From the random stack of unfinished blog posts…

There is a problem with processes and documentation. We tend to use them as shields to prevent us from having to think or make decisions

Software development as a profession is a funny idea. We want treated as professionals, but most of the time we don’t seem to want to act as professionals. We want to hide behind “processes”. We love our processes. It only makes sense, I suppose, since we spend most of our time trying to figure out how to get computers to keep the users stuck in processes. Processes to buy goods and services, or to fill orders, or to handle insurance claims. Things that are repetitive.

Automating processes like that is a good thing – that’s why we do it. It saves time and reduces errors caused by repeating similar actions. It takes the drudgery out of these things and lets the user to get back to their other activities. These other activities are more creative or fulfilling. Or it enables unskilled labor to deal with tasks in a reliable fashion, freeing up skilled labor to do more profitable things.

That is the problem: we are trying to automate processes that make it possible for unskilled labor to develop software. But we’re not unskilled labor – its just not possible for unskilled labor to do these things. Developing software is a creative activity. Creativity doesn’t happen as well when its done under a long list of constraints, which is what process does.

Is all process bad for software development? Just like empowerment doesn’t mean self-management you can’t completely avoid process. Process constrains us to be able to produce software in reliable, semi-predictable ways – to a point. The problem is that we tend to go past that point. We want constrained into tiny boxes, so we don’t have to think a lot, so we can blame the process when we fail. We are risk averse and afraid of failure.

Agile is attractive because we know we have to do something to enable us to produce good software in a reasonable amount of time. We know that the old ways just weren’t working. The problem is, we have years of experience (and beatings) that failure is bad. We clutch to any process we can so that we can blame the process when things go wrong. And because we don’t truly embrace agility, things do go wrong. So we add more process. And things get worse. And so on.

The next time a problem occurs, try something else. Instead of figuring out how to add more process to prevent the problem, think about how taking responsibility could have stopped it sooner. Sometimes you just have to stand up and do what’s right. Admit that you were wrong about some aspect that is now causing a problem. We have “fear of failure” so ingrained that we have to do anything to prevent being seen as failures. And that is just wrong.