Saturday, February 28, 2009

When Is Process Bad?

I've been trying to come up with some rules of thumb as to when putting processes in place probably isn't the correct way to go. I started out trying to pick the tasks that people do day in and day out, but that didn't quite work. For instance, you cannot simply say that a developer writing code should have no processes. That's just foolish. There are some processes that almost all developers should always follow, e.g. use source control, commit early and often, etc.

In that light, my last post was definitely reactionary. Most processes are probably good especially if they're invisible. And if they're invisible, I probably do not even think of them as processes in the first place. At a high level, writing unit tests is part of the process of writing good code. While not invisible, it's definitely a process I don't mind having.

I think processes tend to get under my skin the most when they are used as a management technique when trying to control the results of generally creative, non-repetitive tasks. Writing unit tests is a way of managing change. We always want to manage change the same way so that we know when something breaks before the customer does. But counting lines of code to determine how well the solution to a new problem was written doesn't work. It's hard to put a process in place for non-repetitive tasks because you don't necessarily know what the outcome should be.

The same goes for design. Yes there are certain steps that can be identified as generally good, that you always want to do. You want to make sure that your design solves the users problems. A minimal process for how you go about determining what the users' problems are is probably a good idea. Always observe the user in their natural environment, determine why they are using the software, etc. On larger teams, communicating the final design to many other people probably requires a specific document format so that information is easy to find for all the different teams that need it: QA, development, documentation, sales, etc.

But you can not really put a process around the actual creative design of the feature. Trying to do so usually results in some sort of sign off or management check in that doesn't accomplish what you think it will. It doesn't mean that the best design gets implemented. The manager can't know what is best simply because they don't have the time to do the research and work of their multiple subordinates. Sure they can make observations and recommendations, but the final decision should be the person doing the work. If anything, the only real result is that your subordinates start to feel untrusted.

To boil this all down, I believe that if a manager is trying to control the creative aspect of their subordinates work through processes, they are only getting in the way and sending a negative message to their workers.

Maybe all I've said here is that I dislike micromanagement, that's probably a fair paraphrasing. Regardless, what is the alternative? I said in my last post that there does need to be some sort of accountability and control, where does that come from? If there's one thing I've learned about writing it's to stick to a single topic per post, so you'll just have to wait for my next entry for ramblings on that subject.

No comments:

Post a Comment