I’ve been thinking a lot about process lately, specifically how much process is enough, and how to automate things I do regularly. First of all, I think I’m lucky to work in a place that does not have a burdensome process in order to get anything done.
At its core, process is necessary because we as humans make mistakes quite easily. A process is a set of well-known, written guidelines to follow when doing a task.
I say written, though quite a few processes are mental, because if a process isn’t formalized, it’s more “This-is-how-we-do-things” than a real process. Process has to be repeatable by not only yourself, but by others.
I’m not the kind of person who really seeks after process formalization. I avoid paperwork like the plague, but even I admit that at some point you need to formalize at least something. The real question is how much process is enough. The answer is: exactly as much as you need and no more. The problem is, that amount is very difficult to find. I almost always err on the side of not adding overhead to anything until I see a clear need.
Process should not be added unless there is a clear and quantifiable benefit to the project. And I think the people who carry about the process should be the ones to judge if there is a benefit. Of course, there are exceptions, but I think for standard software projects, less is definitely more.
As an example, suppose I need bug tracking software. I find one that I like, and install it and we use it — it’s perfect for our situation. Along comes somebody else and insists that we switch to the corporate policy, even though my group does nothing like the rest of the company. It’s also a larger, more complicated program, and my group loses control of it. (If this sounds like a real situation, it almost is).
When confronted with this hypothetical, you should be asking yourselves, but what do I benefit? What does my team benefit? What does the product benefit? I do NOT ask what does the company benefit–why does that matter? If it doesn’t help our product and makes our jobs slightly more difficult, then the detriment is worse than any supposed benefit to the company as a whole. I’m sure you could argue this example both ways (for example, if support is an issue, maybe the company is right), but the point is to avoid processes and standards for the sake of themselves.
Here’s the key: Another word for process should be simplification. Having a process should simplify life, even if the actual steps are complicated. It’s the fact they’re written down, or we have automated tools, or that’s it formalized into a printed sheet of paper on a binder at our desk that simplifies it–it takes away our ability to inject mistakes. Does this make us mindless drones? For this process, yes!, but the point is that we shouldn’t be thinking about this anyway! Our minds should be hard at work creating something NEW. The process exists to make sure things go exactly as they need to, for the express purpose of freeing our minds to work on more interesting things.
A good process that I recently had to formalize was our final release build of our flagship product. After too many false starts, we realized that there were too many people, too many resources from various sources, and it was impossible to coordinate it all in someone’s mind. We needed a simple process to be signed off on. So a written checklist was created. We won’t use this for every build–just those that go to the customer. It’s simple, it works, it lets us worry about things worth worrying about.
I’ll talk about automation in another post…
Check out my latest book, the essential, in-depth guide to performance for all .NET developers:
Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order: