Software Development is Not Like Auto Mechanics

pro·fes·sion·al — adj.

1. 1. Of, relating to, engaged in, or suitable for a profession: lawyers, doctors, and other professional people.
   2. Conforming to the standards of a profession: professional behavior.
2. Engaging in a given activity as a source of livelihood or as a career: a professional writer.
3. Performed by persons receiving pay: professional football.
4. Having or showing great skill; expert: a professional repair job.

pro·fes·sion·al·ism — n.

1. Professional status, methods, character, or standards.

[ Source: The American Heritage Dictionary of the English Language, Fourth Edition, via dictionary.com ]

A recent article in The Register claims to discuss the question of "professionalism".

I hear claims like, "but I'm a professional! I shouldn't have to do those things" Usually qualified by such statements as, "I am an expert. You don't need to keep checking up on me, just let me know what you want built and I'll let you know when it's finished. Just leave me alone to get on with the work!"

Interesting, don't you think? I'm actually very keen on professionalism myself and we hear a lot about it in the industry. Most developers are degree educated and there are numerous professional bodies, at least one of which has chartered status. Said bodies also have professional codes of conduct (more about these later), so I guess there must be other people interested in professionalism, too.

I had a little think about professionalism and other professionals that I come into contact with on a fairly regular basis and thought I'd contrast my relationship with them with the relationship programmers have tried to convince me they should have with their customers. One that sprang immediately to mind was the mechanic, or rather the team of mechanics, at my local garage. I've been going to the same garage for years precisely because they are very professional and give excellent service. I'd previously tried a different garage every year until I found the one I was happy with.

I understand the feeling about auto mechanics. We've had similar experiences. However, I think it's wrong to try to compare software development to working on automobiles, even for the sake of an analogy in support of the meaning of "professionalism".

For one thing, a large part of the reason that auto mechanics can give you an estimate (and most programmers can't) is because the mechanic is about to do something relatively simple that he (or other mechanics) has done many times before — even if he is pulling and replacing the entire engine. This is more reminiscent of a project I recall where management asked me to install a corporate calendar on the Intranet. I found an existing calendar solution, downloaded it and plugged it in. It required a small bit of configuration.

In contrast, most of the development projects I've been on are more analogous to designing a new kind of automobile than they are to minor mechanical work. Auto mechanics don't have to work to product marketing requirements and they are rarely called upon to write a design specification!

In the US (at least, in California), the mechanic doesn't even have to have performed this particular task before. He's not giving his own estimate; he's looking it up. There's a book containing a list of tasks. It says "it takes this much time to replace a timing belt". No matter if your car is so rusted that it actually takes an extra three hours to loosen the bolt, the book says how much time the job should take and that's as much time as the mechanic is legally allowed to charge (he can change his rate per hour but not his hours).

Programmers have no such book. Every problem is new and different. There's no place to go for off-the-shelf parts and no listed standards for how much time it takes to write particular function. (Also, automobile shop customers rarely change the specs in the middle of a job. :-)

Even auto mechanics run into difficulties estimating weirder jobs. I recall the situation when my car blew a timing belt as I started it. We had the car towed to a nearby service station and then, for a full week, I was given daily estimates that it would be ready "tomorrow". Unfortunately, a blown timing belt can cause unforeseen complications. It turned out that more valves were bent than had first appeared, some only slightly. The damage wasn't evident until the car was put back together; then the mechanics had to take the engine apart all over again.

In programming, most jobs are weird. If you could accurately estimate the time it would take, you'd already have pre-written code to do the job. Instead, you often don't even have a good design spec (and the design frequently changes as the project progresses).

If you want your team to track progress in a particular way, be it by emailed status reports, notes on an internal web site, or a wall full of index cards, that's a management problem. Don't cite professionalism if the manager thinks the method is justified. Don't blame professionalism if the programmers don't want to play.

Instead, sit down with your programmers and find out what's really bothering them. Do they feel micromanaged? Do they feel that the design hasn't been specified completely enough to warrant itemizing all those tasks? Programmers don't have the habit of doing project management (after all, that's what managers are for). If you want them involved, get them engaged. If you want them engaged, don't get into arguments over the definition of "professional".

After all, in the long run, all the word means is that you get paid to do your work — and we have to assume you're smart enough to do what we pay you to do. Everything else is implementation detail.