I was once asked in a job interview: “how do you know if you have too much or too little process.” I didn’t have a good answer at the time (which is probably part of the reason I didn’t get the job), but I’ve since come up with my preferred way of finding the Goldilocks point in the amount of process. Too much process causes pain for your developers. Too little process causes pain for your customers.

This doesn’t seem like a very novel idea, but I think it makes sense. The appropriate amount of process varies from situation to situation. Designing systems for manned spaceflight is much different than designing a Facebook game. Therefore, it makes sense to look at where the pain exists to see where you are on the spectrum.

With too much process, your developers are unhappy because they’re spending too much time doing meta work and not enough time writing code (even though meta work can be critically important, you should always do exactly the right amount). With too little process (particularly around testing and UX), your customers get a buggy, hard-to-use product that they’re constantly having to update.

One important note is that customers can experience pain from too much process, too, particularly if they have to wait three months for a bug fix. By the same token, developers can experience pain from too little process when every commit sets off a flurry of merge conflicts. Arguably, these scenarios are not from the wrong amount of process, but the wrong implementation of process. Go read The Phoenix Project for a much better explanation than I could give.