So, how can we get clients to appreciate our labors more?

Sometimes it starts with teaching clients how we do what we do. This is especially true when we’re working with someone who has never had their own application built before. Even the most completely obvious things to us are not common knowledge to everyone else. I’ve learned this lesson many times in my career.

Years ago, I took on a freelance project for a client who wanted to build an online recommendation system. I was 22, a relative programming newcomer, and this project sounded like it had a simple objective. The application would offer the cheapest prices on bulk liquor purchases for bars and restaurants based on a database search.

Easy enough.

One weekend afternoon, we met over coffee to discuss the details. I assumed I would get a bunch of data in a neatly organized spreadsheet—a list of alcohol, brands, distributors, addresses, and costs. The user would request a particular bottle, hit a search button, and the app would go find the cheapest price in the system that fit the inputted search parameters. It all sounded peachy. My client and I agreed on the approach and went our merry ways. He’d consolidate the data, and I’d start building this rather Simple, Elegant Example of Exquisitely Crafted Software.

It took me about a week to get the foundation of the application built according to our initial meeting. A week later, we met for lunch to take a look at the Excel spreadsheet he had prepared. It looked a bit hairier than I was hoping for. It wasn’t the simple five-column table I was expecting; I bit my lip and smiled sheepishly.

“Well, the prices change based on how much quantity of the product you buy,” my client said. There were two other columns: a maximum and minimum quantity of alcohol that had to be purchased to obtain a specific price.

Fair enough, I thought. After all, that is the whole point of bulk purchasing. Back to the drawing board for a few slight tweaks to my data model and off we go.

The following day, I had the solution. I added a couple of additional fields, BeginRange and EndRange, to my database. I then modified the application so that it would accept a quantity value and adjusted the SQL query so the selection would filter those records where @quantity >= BeginRange and @quantity <= EndRange. The system was perfect again!

When we met the third time, my client looked puzzled. My code was beautiful, but there was something missing in the behavior of the system. As he played with the software, he noticed there were a few more levers missing.

As I would soon find out, in real life customers get discounts for coupling similar products together. The concept of bulk didn’t just live per product, but buying X amount of whiskey might afford you a discount on Y amount of vermouth (Manhattan, anyone?). In addition, the discounts differed based on how much whiskey a customer purchased. Maybe we ought to throw in a few free jugs of Maraschino cherries as well.

From his end, the behavior of the system seemed off. In his experience, these deals, found by calling real human distributors directly, were commonplace. From my end, I didn’t have the data or conditional logic to deduce any of this. In addition, even if he could get me all the data I would need, I’d still require a lot more time to figure out exactly how to organize it. Would I need to build some separate table of dependencies to handle discounted products based on the purchase of another product? Should I build a “common mixed drink” feature so the app could intuit what drinks a customer could make out of their purchases in order to offer other discounts? Most importantly, was there more madness to the model I would find out after this?

It dawned on me one day that I was not, in fact, building a concise, well-defined system to mine spreadsheets of data to harvest the singular right answer. Instead, I was building Larry^TM, the alcohol distribution manager. I was trying to account for decisions that were not easily deducible. Larry^TM gives offers based on his relationship to his customer, his own forty years of experience, and a general hunch or two. He knows what will drive customers back to his company as opposed to the other one hundred distributors he competes with.

Why wasn’t I told all of this new information in the beginning? Was my client just hiding it from my prying ears, or did he not figure that it was important at the time?

Here, in full daylight, arose a fundamental misconception that lots of nontechies have about software. As programmers, we are primarily organizers of logic and information. Our jobs are mainly about pushing, pulling, manipulating, and displaying data. Most of us aren’t in the business of artificial intelligence. We can’t easily write programs that recommend or guess. Even “recommending” or “guessing” is a product of some set of defined, describable logic. Yet, sometimes, that’s exactly how the outside world perceives this work: some kind of magic black box that can figure out all the loose ends even if we don’t give it all the information it needs.

When I started to explain the difference between the software I was building with the software he was looking for, my client said he’d get back to me. Years later, my code is still sitting on an old laptop and is affectionately known as my dust collector/paperweight.

Looking back, the client-developer relationship became clearer to me. From my client’s point of view, the Web, software, and databases—all these “technical” things—were all a mysterious haze of magic. There was some part of him that believed code could magically take care of a few undefined bits of logic, even if these small loose ends were the things that made this type of application really complex to build.

In any project, there will be a certain amount of unknown. This is the nature of our work. Rarely is an idea completely flushed out before we transition into development. Also, even when everyone thinks it is, it really isn’t. Weirdness has a way of dodging our minds when we’re still talking about software; it tends to surreptitiously unveil itself only when we start building.

Maybe that’s why we build a love-hate relationship with our clients and customers. What is seemingly so obvious to those of us toiling “in the box” is sometimes lost to those on the outside, because it’s in the box where the idea must finally be realized. It’s in the box where we know, full well, whether we have something concrete or we don’t. It’s in the box where the real struggle occurs.

That’s why there’s frustration from the outside as well. From their vantage point, they’ve thrown you lots of information and requirements and detail—certainly enough to get you started. They let us know what they want, and they are waiting....

Further, when—days or weeks or months later—they see something that isn’t quite what they had hoped for, they too are somewhat deflated. The box isn’t as magical as they had thought.

When these times arise, take your client inside the box. Take them there early, if need be. Show them what you’ve been working on. Step them through the actual code if you must. Get them involved in thinking through the questions that naturally come up to you when you’re in the midst of programming.