RSS

I’ve been programming in one form or another since I was eleven or twelve. That’s over two decades of coding. Not as much as some, but still more than most coders my age. I started with BASIC, learned only enough of the infuriating and overly verbose COBOL, and finally moved on to more useful languages when I was about nineteen.

It’s a mysterious process to some. Very often fellow high-school students would come over to my computer and look at what I was doing. They would look at the incomprehensible stuff on the screen and ask, “How do you know what to type?”

How does one answer this question? When I was young and socially inept I would try to give the questioner a little explanation about programming languages, which I think was a larger answer than they cared to endure. What they were really wondering about (but didn’t know how to ask) is how so much (seeming) gibberish can do something meaningful. The problem was that programming was a mystery to them. They were familiar with other complex tasks like playing the piano, building a house, flying a jet, or writing an essay, but none of them had any idea what programming was or how it worked.

The next generation doesn’t seem to have this problem. My younger brother (thirteen years younger) doesn’t know how to program, but he has some sort of grasp of the concept that these are instructions for the computer. He has some sort of framework to hang it on, and coding is not arcane magic to him.

But this ignorance endures in previous generations, and causes all sorts of professional problems when I end up doing work for a client who knows nothing about what coding is or how it works.

CLIENT: Quick! We need you to build a house by next Monday!

ME: Well, you don’t usually build houses that fast, but what sort of house are you looking for?

CLIENT: Oh, we don’t have all the details yet, but we know we are really going to need it by Monday.

ME: (Deep sigh) Okay, so give me some sort of rough idea. One story or two?

CLIENT: Probably one but we might decide on two later. I’ll get back to you on Wednesday.

ME: I kind of need to know that now. So is it going to be brick or wood?

CLIENT: Just make it an option.

ME: That’s what I’m doing.

CLIENT: But for later.

ME: Wait. You want to be able to switch between wood and brick after I build it?

CLIENT: That would be great, yeah.

ME: You can’t… I don’t… That isn’t… Look, it can’t be both. I just can’t. It has to be one or the other.

CLIENT: (disappointed) You sure? Okay then. I’ll talk to my boss and see what he says. I’ll get back to you tomorrow.

ME: I see. So how big is the house?

CLIENT: How would I know?

ME: How big do you need it?

CLIENT: Well, just make it as big as the property…

ME: Which is?

CLIENT: I’m not sure. We have a couple of properties we’re looking at. One is a half-acre, the other is a full acre.

ME: So you’re not sure what you want, what it should look like, or where you want it, and all you DO know is that you need a half-acre house by Monday?

CLIENT: Is that a problem?

ME: I really need to know these details.

CLIENT: Look, just get started right now, and we’ll fill you in on the details as we come up with them. I do have the details of how we want the roof to look, so you could start on that while you wait for the other info.

Keep in mind that this client is not a jerk, a moron, or a sadist. The problem is that they have no idea what I do or how I do it. When I tell them I need the specs of how the program needs to work, they will invariably tell me what they want the dialog boxes to look like. This is the part they see and understand, and this is the part they have in mind when they tell me what they want. Once the interface is done, then they can iron out all those “other details”, like what the thing does when you push all those buttons.

The hardest part of coding isn’t coding. The hardest part is getting people to tell you what they need.

A long time ago I ended up with this aphorism: “To define is to limit.” A specification consists of a description of all the things that I am not going to do. What’s left is what I deliver.

If you can’t tell me what you don’t want me to do, I will work forever because I will try to do everything. The sooner you tell me what you don’t want, and the more you exclude, the sooner I’ll be finished.

“Keep in mind that this client is not a jerk, a moron, or a sadist. The problem is that they have no idea what I do or how I do it.”

If this is true, then doesn’t it make sense that you have to explain what is possible? It seems odd to me you are generally complaining about how unknowledgable they are, but in the same breath you say it’s not their fault. I understand it’s frustrating, but isn’t that what you are paid for?

What you are saying is very true and apliceable to all areas of living I believe.
To see a problems solution you need to define and make the problem visible.
So what you do is to create a ‘questionnaire’ to try to ring in what your customer / problem is about.
After that you will try to reduce the problem even more.
It’s also a good procedure to keep some kind of ‘journal’ describing the steps you took for later perusal.
Whatever profession you’re into it will save you some effort next time if you already have created a set of lose rules guiding you.

This post is hilarious, but sadly, it’s very very typical. The client isn’t an idiot, but he knows nothing about “building houses”, or more to the point, software.
However, understanding that the client doesn’t know anything doesn’t make it any easier.

My former employer tried his utmost to educate his clients as far as possible, but they either showed complete disinterest, or just didn’t get it anyway.

To expand on what Steven said, the spec document is not an option, but an absolute prerequisite. It’s a developer’s protection against the ignorance of the client.

This spec stuff is why in 25 years of programming, mostly in database engine internals and embedded-system programming, I never, ever wanted to work on anything where I had to worry about colors or fonts.

People usually have a good idea how they want their custom database engine to work, but a website? They’ll iterate over it 50 times before they “like it” – and they’ll change it because their kid hated it.

this and the medieval tech support video that’s floating around sums up my professional life.

Whenever someone says “oh, I don’t care how it looks, as long as it’s nice” you’re in for a lot of trouble, because they actually have something very specific in mind that they can’t describe, but they will know it when they see it .. good luck figuring out what it is!

Believe it or not, but architects and construction workers have the same problem with building houses for some of their clients. Just because most of us are familiar with the way a house is built, there are still the same problems with people knowing what they want, and how long to wait for it :-)

I think you are wrong on the middle one. If I want to buy a car, I need to have some basic knowledge about cars. If I want to buy software, I need to have some basic knowledge about programs, such as “we want it to do X”.