Software Development Processes

Today, the software development processes are a topic of heated discussion. The whole industry faces a stiff breeze from the agile faction that promises a new course on the quest for high quality software. The agile department on the other hand is confronted with FUD like not having processes at all.

So what are processes in a software development context? When we refer to processes we usually mean rules that specify when or how to do work. Of course we always follow some informal "process" when we work, but I'll refer to processes in the more formal sense of defined rules.

When I was a kid many of my friends had to finish their homework before they were allowed to play outside, while I was free to do my homework as long as I didn't get problems at school. The school thus imposed a when-process on me (I had to finish my homework for the next class) while my friend's parents created a process for their kids.

The school is also a nice example for how-processes. My eight year old nephew Marvin will learn how to do subtraction by hand this year. His teacher summoned all the parents and told them that this year a slightly different version of the borrowing algorithm will be taught instead of the method that pupils learned in German elementary schools for over five centuries (the difference is to "borrow" -1 from the minuend instead of +1 from the subtrahend if the digits can't be subtracted directly). This way the school defines how the children do their calculations - if they use a different way, they'll get bad marks.

So now that we know what processes really are, how do we find the best processes for a software development process? As always, this is a highly recursive problem. If processes help at the lowest level, they probably will help us to develop better processes. So we have to find processes to optimize the processes that optimize the processes. The good old fixed point problem - again.

Usually you try start a fixed point recursive problem with a trivial termination case. There's an easy recursive when-process.

When (not) to use processes.

If people always did the right thing, we would not need processes at all. In a software development environment we usually assume that all people work towards the same goal - delivering high quality software. But even if all team members had the same goals and were motivated to always do the best possible task for the company, they usually have different opinions on what is "best". Those different opinions may lead to childish fights about who should have done what and who's responsibility it was. Both parties think their solution is the best for the company and in this case a defined process can help to resolve conflicting goals.

And this is exactly the mother of all processes: Use processes (only) to enforce decisions when you're quite sure that no superior outcome can be achieved without defining processes. This is often hard to anticipate. At school I used to do my homework in the morning of the day I needed it, sometimes even during the breaks. But I always did all my homework myself. Some of my friends who were forced to finish their homework used to lie about finishing it, just to copy it at school. Those usually didn't do very well. Here the process obviously didn't help at all.

So let's try to get to the next step: what is the most obvious process that a software development team is willing to accept but wouldn't start on their own?

Use a process definition and optimization process.

Let the team figure out some processes for themselves. Let the team decide on the processes. Since the team usually has most experience in what runs smoothly and where to find the rough edges, the team should be able to identify processes that work for them. The team needs to buy into the processes anyway, and the biggest chance to get them to buy in is to have them decide it.

Of course not every team will discover processes like pair programming and test driven development for themselves. But they don't need to. It's no problem to present a fine set of processes, like XP or Scrum to the team for evaluation.

If the process definition and optimization process doesn't work, impose processes.

Let's face it: some teams just don't want to define processes or have anything to say about the way they work. They just want to get their paycheck and do as little as possible just so they don't get fired. And this is not a small part of the human species. In such a team you have to be weary because many good processes will fail, and you'll probably end up with a myriad of process definitions that are used as an excuse not to think.

But as long as you didn't try the process definition and optimization process you don't know for sure that it doesn't work. Software development is a highly creative process where motivation can cause a difference in productivity of an order of magnitude. Development processes are tightly coupled to a good work experience and thus to motivation. All this leads to the conclusion that software development processes are a very important aspect in software development.

Today, as a grown-up I'm mostly responsible for the processes I use myself. Nobody tells me when or what to learn, when to work out and what to eat. And I find that I learn more, work out harder and eat healthier. A coincidence?