I love software process. My passion is finding ways to build software faster, but better technology is only half the battle. The other half is a people and organization problem. Process can do wonders for that half.

Among some of the benefits process can bring to a project are:

• Ensuring everyone is working on the most important thing
• Coordinating efforts to distribute work effectively
• Adding little nudges to improve code quality such as automated testing and code reviews

That last bit is where process can become a disaster though. Process is most effective as a nudge. Building software is a complicated process and it is easy for developers to forget to do a handful out of the hundreds of things they are constantly thinking about. Process can provide safeguards for developers to remember to do those things.

Process can not be used as enforcement.

That is contrary to how many view process. They treat it the way we treat our legal system. Every time something bad happens, the solution simply must be a new process implemented in order to prevent the situation from happening again.

Sometimes that works, but it requires all the developers to believe in the new process. Let’s use automated testing as an example.

Your product has a bug. It was pretty bad. The bug would have been easily caught by automated testing. After fixing the bug, a new process is implemented where all new code requires automated testing. Great! Now all our future code is bug free right?

Not quite.

If the developers on the team don’t believe in automated testing, then they may not write it. A code review can be enforced to check for them, but that won’t work if the reviewer doesn’t believe in automated testing.

The solution to that may be engineering management checks on it. What’s the reporting ratio though? 4 developers to 1 manager? 8 to 1? Not all tests are created equal. A manager with a team of developers who don’t believe in automated testing will only be able to check that they have built some tests. That manager will not have time to check that they have built good tests that would actually prevent bugs from being introduced.

Process can be used to help remind a developer who believes in automated testing that they should write automated tests. Process can not force a developer who doesn’t believe in automated testing to write automated tests that are actually useful.

Another thing to consider is that all process has costs. The only process that should be used is one where the benefits outweigh those costs. For example: companies with large scale software systems will have systems that are complex enough to require a senior developer or software architect review designs for new systems. Performing a review has the cost of time for at least two people: the reviewer and the developer whose work is being reviewed.

Not having this review could result in rewriting large swathes of poorly designed code though. The cost of a few hours for a review process outweighs the cost of the days, weeks, or months needed to fix that code.

Needing to get approval from one or two people makes sense. But what if some reviewers missed things? Do we start adding more reviewers? Does every project need approval from 6-8 people now? How do we make sure you can actually schedule a meeting with all those people? How long does the start of the project get delayed in order to make sure everyone can make the meeting?

Now we’re entering in the territory where the cost of the review is going to exceed the benefits. Most of the problems would have been caught by only one or two people. To get the remaining number of problems by requiring more people to review the software design, we delay the project by a few days (or even weeks). We’re also using up the time of a lot more people. Instead of trusting our reviewers to learn and get better, we have burdened the entire organization with an expensive process.

Many people view process as a way to remove risk from software projects. But software development is an inherently risky activity. Attempting to remove all risk with process will end up introducing massive costs in time. Eventually this cost becomes untenable.

I once worked with a manager who believed it was possible to remove all risk from software. He wanted the 5 lead developers to review the code written by all two dozen developers. So every lead performed code reviews for over two dozen people and every developer had their code reviewed at least 5 times. Doing that properly would have taken a single lead more than 24 hours in a day. Even if there was enough time, how much more benefit would the extra reviews have gained us?

Time is not infinite. Spending it doing one thing means not spending it doing something else. When time is unwisely spent on low value processes, it prevents the development team from working on something that could produce a high amount of value for the business. Competitors who make better decisions around processes would end up bringing more value to their customers in less time. That helps them steal customers.

The quest to lower software risk at all costs has inadvertently created a huge amount of business risk.

I like to think of software process as seasoning for food. If you have a great cut of steak that’s cooked well, then a little seasoning is only going to enhance it. Too much will ruin the steak since all you’ll taste is seasoning. On the other hand: if you have a pile of poo, no amount of seasoning will make it not taste like a pile of poo. The seasoning can only enhance the strong foundation of great food.

Process can only enhance a team that already works well. If a team communicates well and each member trusts each other, then there is a strong foundation to work with. Adding process tweaks the team’s workflows and makes them more productive.

No amount of process can help a dysfunctional team. The problem here isn’t there isn’t enough process or the wrong processes are in place. The problem here is with the team’s culture. Process is an easy thing to fix, which is probably why many people think of process solutions first. But that’s just avoiding the underlying issues that really need to be tackled.