Programmer Musings

"All you have to do is..."

What is it about the programming field that makes everyone believe that it is easy? I can't count the number of times I have had someone tell me:

• All you have to do is...
• How hard can it be? You just...
• It won't take that long. It's just a little program.
• etc.

Most of these people have never written a line of code in any language. Many of them only hve a vague idea of what a programmer does.

I sometimes wonder if other professionals get this. When a patient disagrees with a doctor's opinion, he may get a second opinion. I doubt he would say "All you have to do is a little surgery, how hard can that be?" When someone is hiring a company to build a house, they probably don't tell the contractor "Oh it couldn't possibly take that long. After all, I've told you everything you need to know. Just go build it."

When dealing with most professionals, you may not agree with their decisions, and you may go with a second opinion or, even a third; but you normally make the assumption that they know their field. They might not have all of the particulars nailed down in their first estimate. You don't expect them to change their estimates by a factor of ten just because you want it.

But in software development, this seems to be the norm. Customers, salesmen, and even some managers expect to be able to override a programmer's professional opinion on a whim. Some might say that our estimates are more fluid because no one understands software as well as, say, bridge building. I would point out that people rarely overrule a doctor's professional opinion, even though I've had my share of diagnoses that weren't any better than a wild guess.

In addition to the professional aspects of this problem, it spills over into everyday conversation. In my experience, people always seem to assume that what I do for a living is easy. They come up with an idea that will make them big bucks and I should be able to make it happen in a few days for less than a hundred dollars. Many of them seem offended when I don't volunteer to give up my weekends and evenings to make their dream a reality.

Even professional customers (and employers) want to be able to negotiate time estimates and costs. It seems they believe that their five minutes of thought means more than the years I have spent working in the field.

I know others have had this experience, and I would like to know: does anyone have a good technique for explaining this idea to a potential customer. How do we make people understand that the programs we write are real, even though you can't touch them? How do we get across the mind-boggling complexity of even relatively simple problems?

Maybe it's just that the field is so new that people don't have a grasp of what it takes. If I told you it would take me a year to design and build a new car from scratch. No one would try to convince me that it should only take 6 months. (Although, they might suggest I was nuts and it would take more like two or three.) So, why should a program with even more individual moving parts seem trivial.

It does tend to make one think.

Domain Knowledge and Programming

Over the years I've been a programmer, there seem to be two distinct areas of knowledge for any project. The first relates to programming. The second relates to the domain of the project. Over the almost two decades I've been programming professionally, I have worked in many domains. Interestingly, I have never started working on a project as a domain expert.

At different times, people have told me that they were looking for a programmer with extensive experience in X (whatever their domain is). I have even seen people go so far as to suggest that they would not hire a programmer who did not have a degree in the domain of interest. This seems completely backwards to me.

When hiring a construction company to build a bank, do we only consider companies that employ bankers? When finding a mechanic to work on an ambulance, would you only talk to those with EMS training? So why would you require a programmer to have a degree in biology to program for medical research?

Over my career, I have come to the conclusion that we programmers should always develop some domain knowledge as part of a project. But, we never need to go too deep. The real need is to understand enough of the domain to be able to translate the real knowledge of the domain expert into a form that the computer can execute. Our real skills come in this translation, not in the knowledge of the domain. More importantly, what domain knowledge we have should match that of the customer. This is only guaranteed if we learn from the customer in the process of doing the job.

As an example, let's say that I went to work for an engineering firm. I have an electrical engineering degree, so this seems like a natural fit. However, my knowledge of the electrical engineering field is now twenty years out of date, and fuzzy to boot. Would that knowledge be a help or a hindrance to any work I might do.

Having some knowledge of a particular domain might be an advantage. Having no preconceptions about the domain might be a bigger advantage. In many of the programming positions I have held, I managed to do some good by approaching the problem differently than the domain experts. The key is to extract the knowledge from the domain experts in a form we can execute. If I accomplish that goal, I consider the project a success.

My field is software development. As such, I need an extensive knowledge of tools, methodologies, and techniques for the development of software. I also need the kinds of skills that are needed to develop software. One of those skills is the ability to stuff information into my head and retain it long enough to make it make sense to a computer. Most of the best programmers I know regularly do the same.

The reason for this rant is a problem I have run into several times in the last few years. I have been talking with someone about a job or a piece of code they want written and they decide either that I can not do the work or that I should be paid less because I am not an expert in their field. I have heard similar comments from friends. One fellow programmer told me how an employer in a medical research institution reduced the amount they were willing to pay him because he did not have a degree in biology. Now, I am pretty certain they had plenty of biologists on staff. But, they were hiring for a programming position, and a biology degree does not make you a better programmer.

I'm not sure what it is about our craft that makes people to think that there is nothing to it. Many seem to believe that they could pick it up if they just expended a little effort. But, of course, their field is something that you need loads of training to be able to do. Not like programming.

Most of the better programmers I've known seem to think about it differently. They assume that most people's area of expertise requires work, knowledge, and years of practice to be good. They also know that it takes similar work, knowledge, and years of practice to be good at what we do. That's why most of the code that I've seen written by domain experts is such a mess. They see code as a minor sideline away from the real work. We see code as the artifact we produce to help other people get on with the work they are interested in.