Process Versus People

I saw an article the other day and the title was fantastic:  How terrible code gets written by perfectly sane people.  The author was porting code from Python to Node and was looking forward to the challenge.  What he didn’t expect was the code, written by a group of senior developers with good skills, sucked.  (OK, he didn’t use the word sucked, that’s my interpretation when he said the code was “the product of a room full of babbling monkeys copying code randomly from Google.” See?  It sucked.)

I’m sure we’ve all seen examples of this type of code.  We’ve may have even written this type of code.  So the author goes on to list the reasons why this may have occurred:

  • Giving excessive importance to estimates
  • Giving no importance to project knowledge
  • Focusing on poor metrics such as “issues closed” or “commits per day”
  • Assuming that good process fixes bad people
  • Ignoring proven practices such as code reviews and unit testing
  • Hiring developers with no people skills
  • Agile and done?  Um, no.

There are so many things to talk about and so little time to write that I’m stuck on what to say.  Well, maybe not.

“Assuming that good process fixes bad people”.  Sorry to sound stereotypical, but that reminds me of … well … government.  We put processes in place to “fix” things, but they don’t.  A process helps you determine if the proper things are done, not if things are done properly and therein lies the issue.  We have a problem so we create a process to solve the problem.  But are we doing the right steps.  Are we doing the steps correctly?  It doesn’t matter because the process was followed.

The idea behind changing a process is to make something “better”, but that’s a difficult word to define.  Does it mean CYA or does it actually mean that something is better (more efficient, more effective) for the organization?

There are some processes, no, not processes, “controls” that need to be in place.  For example, business users need to approve deployments into production.  It is their application so they get to determine if something goes in or not.  How the organization implements that control is the process but the exact implementation can be different depending upon circumstances.  In our case we use DeCo for manual deployments but BuildMaster for automated deployments.  The control is still there – business approval – but the process around getting that approval is different.

If there is a problem take a look at what you are really trying to solve and base the solution on that.  Don’t create a process for the sake of creating process.  Don’t assume that everything will follow the same process.

A process, whether a good or bad process, is still just a series of steps.  It does not indicate whether or not things are done properly.  How many times has my team implemented something into Production only to have the application fail?  Too many times.  It is not the process which is at fault and, like the author of the article said, we are “assuming that good process fixes bad people“. But they don’t.  A process can be streamlined, it can be optimized, it can be hermetically sealed in a storage bag so that it never loses it’s freshness, but it is still a procedure.  People can follow a procedure and still end up with problems.

The problem isn’t the procedure or lack of procedure, it is that people make mistakes.  People are fallible.  If you “fix” the people, give them the necessary training, give them the necessary support, then you don’t need as many procedures and you will still end up with a better overall system.  We often create processes when we should be training people.

Leave a Reply