thirdbIT

Our next-youngest client, Ari (4), executed this project without our assistance. It worked out magnificently. Take two glossy magazine pages, a bunch of tape, and wrap pages around feet. Apply tape. Voilà: Magazine slippers / goblin shoes / “skates”.

This is one reason not to ration tape.

First, a parent hack. Got kids? You should be reading Parent Hacks. Not got kids? Read on anyway, I relate the whole thing to user requirements at the end.

The hack: As soon as your kid is old enough not to eat it, buy a multipack of store-brand magic tape. Provide your child with the tape, scissors, the contents of your recycle bin (purged of dangerous items), and a box of broken toys and other small household items. Now leave your kid alone with the stuff.

The most important part of the hack: do not ration the tape.

Discussion

Ari loves tape. We used to ration it. We value conservation, and using up gobs and gobs of tape seemed useless, expensive, and just plain wasteful. We didn’t understand the things he did with it. They were incomprehensible and often ugly. He used too much of it. It all seemed pointless. Three things made us change our minds:

First, we realized that tape is so cheap it’s essentially free, even when used in quantity like Ari uses it. Ari can easily spend an hour on a taping project, without needing, wanting, or even acknowledging parental attention. A babysitter costs us at least $12/hour. So not rationing tape actually saves us money.

Second, we realized that the tape served the goal of conservation by enabling the transformation of, basically, garbage, into toys and games and arts and crafts. Yes, eventually the stuff did end up on the curb anyway, but it enjoyed a (sometimes very long) second life as a more-or-less elaborate Ari contraption.

Third, we realized that tape is a non-toxic, easy to clean up, and remarkably versatile project supply that allows both two- and three-dimensional constructions. Glue is also versatile, but much, much messier.

Finally, we realized that while the things Ari made with the tape seemed senseless to us, they were valuable, important, and even beautiful to him. This is often the case with our childrens’ projects. We’ve come to realize how often we say no to kids, just reflexively, for no other reason than that what they want doesn’t make any sense to us, the grownups. (”No, don’t use up all that tape. What do you need all that tape for? Why do you have to tape the giraffe to a stick and hang rubber bands off him? What’s so important about putting those toy people in a cardboard-reinforced tape shell and carrying them around in an old purse? What the hell for???”)

When we find ourselves saying no, we stop and ask if there’s really a good reason for the ‘no’. We try to say yes, when we can. And so, we say yes to as much tape as he wants, whenever he wants.

What this has to do with clients:

Clients, like kids, often want, do, and care about things we don’t understand. It’s our job to try to understand them, and it’s difficult, exhausting work. It’s much, much easier to dismiss them. “No, what do you want to be able to download spreadsheets for? Who cares about what color that dumb little button is? That’s a ridiculous process anyway, why should I make the software conform to it?”

We want to build software that we care about, and that we understand. But that’s not our job. Our job is to help our clients do what is important for them.

“How can you compare clients to kids?” you may ask. “What kind of whupped parent are you that you treat your kids like they’re your clients?” or conversely “Isn’t it a little insulting to treat your clients like they’re children?” I’m not arguing for not setting limits for your children. I’m arguing for respecting them as people whose values we do not always understand, just as we respect our clients as people whose values we do not always understand. (Software development is just like anthropology, only better paid, I’ve always said.) We have broad and deep expertise in many areas that our kids don’t, and in order to help them do what is important for them, we’ll have to draw on that. But the same goes for clients. We don’t let our kids go without brushing their teeth, even though it’s not important to them, because we understand that toothbrushing is part of the infrastructure of living. We don’t let our clients’ projects go without version control, even though they don’t care about version control, because version control is part of the infrastructure of software development. We should not be slavishly trying to meet our clients’ every needs any more than we should do that with our kids, and even when our kids are at their most infuriating and most incomprehensible, we should remember that to them, the things they care about are every bit as important as the things we care about are to us.

We’re not the boss of our kids, and we’re not the slaves of our clients. We’re just the consultants.

The other day we put a prototype build of a web app up for our clients. Fire away at it, we said. Tell us what is wrong with it! We even had a section in the release notes called “How to be a QA person” (It’s a small project, we don’t have QA, hence our clients are, basically, QA).

Of course, we were pretty proud of our app. Of course, they came back with lists and lists of embarrassing bugs, complaints, features they didn’t understand, etc. The lists were not bracketed by nice polite “we love the app, we’ve just got a couple of teensy little issues with it.” Although the emails they came back in were entitled “Bugs 1, 2, 3, etc.” not everything in the lists were actually bugs. Developers are very defensive about “bugs”. The typical user considers anything that doesn’t work the way he wants/expects it to to be a bug. The typical developer considers bugs to be only things where they, personally, wrote code whose logic was not correct.

So Max comes in to me and says “wow, what do we do about the clients and all their bug reports?!” Our immediate emotional reaction to their emails was that they were irrationally pissed at us and didn’t understand anything about how software development works and were a pain in the ass and were probably going to fire us for giving them such buggy code.

But then we were able to sit back, take a deep breath, and reason together:

First, our clients did exactly what we asked them to do, and they did it well. They gave us fantastic feedback on the app that would help us focus on the most valuable changes we could make for them. When clients don’t give feedback, you’re screwed, because you don’t know how to make them happy. Our first emotional response is normal, and we’ll probably never get rid of it. In fact, we probably shouldn’t get rid of it, because the emotional response is there to kick our asses.

However. (And this is my completely based-on-popular-science-books-by-eminent-yet-readable-professors-theory). When dealing with other humans, we humans expect a fat pipe. We evolved for person-to-person, face-to-face contact. Our faces, bodies, and voices are unbelievably expressive. Compared to the fat pipe of person-to-person contact, words in email are a trickle of information. So when we get an email that elicits any kind of emotional response at all, our brains start flailing around wildly, looking for all the meta-information we expect to come along with it: the expression on the face, the tone of voice, the direction they were looking, and so on. And when we can’t find it, we make stuff up. In no time, we’ve filled up the fat pipe and satisfied our “what do we do now?” programming with _entirely false, absolutely imaginary information_. Those of us who are naturally pessimistic generate false, depressing information. This makes our initial, proper and correct ass-kicking emotional response escalate into a neurotic, counterproductive, self-perpetuating emotional response. Not good for business.

One moral of this story is that developers should not take user complaints personally. This is obvious but easily forgotten. The other moral of this story is the one I’m really interested in: when our brains don’t have the information they expect to have, they just make it up. And it’s really easy not to notice when it happens, because the made up information looks just like all the actual-based-on-fact information our brains have collected. Hence the unreliability of witnesses.

The lesson, then, is that, for stuff that matters, _don’t assume your brain has the facts right_. Take the time to sort out what you can possibly have evidence for from what you just made up because you _didn’t_ have any evidence.