csixty4

It’s so easy to blame machines when things don’t work. They don’t leave dog feces on your desk, or fill your car with styrofoam peanuts when they’re pissed. Most monitors are all shiny & reflective — maybe we need to be taking advantage of that and looking more closely at ourselves.

Jeff Atwood (Coding Horror) posted today about how many problems in software development are actually people problems. He starts his post by talking about a post from Bruce Eckel (author of Thinking in Java and Thinking in C++) about more or less the same thing, but from a different angle.

Eckel points to problems in software development stemming from how most people in our field aren’t passionate programmers. They don’t go to user group meetings, or read blogs and books on programming. Atwood focuses on the need to get along with your co-workers before you can tackle a project as a cohesive team. My focus is more on processes.

Gerald Weinberg (author of a favorite of mine: Understanding the Professional Programmer) summed it up pretty well:

“No matter what the problem is, it’s always a people problem.”

I’ve been tempted to substitute “process” for “people”, but that’s not really the case. Failures in process are either a sign of failure to pick/design a good process, or failure to adhere to the process. Both have their roots in “people problems”.

Take a look at Steve McConnell’s Classic Mistakes Enumerated. You don’t need to read the whole thing, just scroll to the table at the bottom. There are 36 “classic” causes for project failure there. “Missing semicolons” didn’t make the list, nor did “ran out of disk space on the dev server”. Those sound like pretty technical problems compared to “Code-like-hell programming” and “Shortchanged upstream activities”. Really, though, “people problems” are at the roots of technical problems. Someone wasn’t prepared, or they did something irresponsible. The compiler just brought it to someone’s attention.

There was once a monk who would carry a mirror whereever he went. A priest noticed this one day and thought to himself “This monk must be so preoccupied with the way he looks that he has to carry that mirror all the time. He should not worry about the way he looks on the outside, it’s what’s inside that counts.” So the priest went up to the monk and asked “Why do you always carry that mirror?” thinking for sure this would prove his guilt.

The monk pulled the mirror from his bag and pointed it at the priest. Then he said “I use it in times of trouble. I look into it and it shows me the source of my problems as well as the solution to my problems.”

– Story about the Tao, mentioned by Reg Braithwaite (and I promise that’s the end of the name dropping)

One way we try to prevent human failures from causing trouble is by setting up processes with checks and balances to keep us honest. People get all excited about processes — “oh, this new agile process is going to double our productivity!”. But as soon as it becomes extra work, it gets thrown out the window. Let’s face it, writing code is fun — that’s why many of us got into this industry in the first place. You don’t see many people writing specs or test plans for kicks on the weekend.

I’ve tolerated this cavalier attitude, probably more than I should (a subject for another post). Most of the time, it’s resulted in projects going way over estimates, and led to buggy/inefficient code, lost orders…that sort of thing. Oh, sure, a few times it actually did pay off, and that’s a shame. It’s a shame because those rare successes outshine the negatives and everybody thinks they can be Superman this time, too.

In the industry, we call our generally accepted processes our “best practices”. That’s not a strong enough term. Developers and project leads should see their processes as religions. Not willing to commit yourself to blind faith? How about calling them “rituals”? After all, washing our hands is a ritual, and we do it because it’s healthy. But we’re not born knowing that. Someone instilled that discipline into us, and now we always do it, not always conscious of the health reasons that started the practice in the first place. Development processes should be the same way. “We don’t start coding until we have a solid set of requirements with the client’s signature” would be a good one. “We multiply our gut estimates by 2.5 to accommodate client communication and QA” is one I need to get back to doing.

And, yes, heretics should be burned at the stake. We shouldn’t (but often do) put up with rebels in our midst. They give people bad impressions of our particular teams and the industry as a whole. Is there a Jack Chick for software development? There needs to be. I’d like to hand out copies of “Regression Test or Burn in Hell” at this year’s Penguicon.

This entry was posted on Thursday, January 10th, 2008 at 1:17 am and is filed under Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.