communication

It's All Just Software

I had a meeting with a customer (let's call her Kate) last week, and she wanted some changes to a web-based messaging application that my group owns and manages. That meeting didn't exactly go as planned.

Blame Tennis

Here's how the conversation between myself and Kate went:

Matthew: OK, so the request you submitted said you wanted the icon on the task bar to flash orange whenever a message comes in from the messaging application, right?

Kate: Right.

Matthew: Unfortunately, that kind of thing is basically impossible in a web app.

Kate: What? Why?

Matthew: Well, it's a completely different environment. The old app was a Windows application, where this kind of thing is trivial to do. But now, the app is a Web app, so it's a totally different environment.

Kate: I don't understand.

Matthew (exasperated): ...See, the web app only exists in the browser, and the browser exists in Windows. But the code can only call it's container. So the web app can call the browser, and the browser can call Windows. But the web app cannot call Windows.

Kate: You just said it could. The app can call the browser, and the browser can call Windows. So the app can call Windows and make the icon flash orange.

Matthew (confused): No. That's not how it works, because if it did work that way it would be a massive security risk. Imagine a malicious website being able to screw with Windows without you downloading something. That would be incredibly bad.

Kate (desperate): But the old app did that!

Matthew (resolute): Right, I know, but that was a Windows app, not a Web app. Making the taskbar icon flash in a web app is basically impossible.

Kate (angrily): It can't be impossible! They did it before.

And around and around we went. She wants something, I say we can't do that the way she wants, she says "but you did it before," ad infinitum. It's an endless game of blame tennis, where she serves with "we did it before!" and I return with "we can't do that now!" over and over until one of us collapses from exhaustion. It's maddening.

Throughout the game, it struck me as odd that she held steadfast to the idea of "well you did it before, why can't you do it again?" Because, to me, the very idea of a web app making Windows do something is preposterous, laughable. It's so far removed from "normal" web development as to be obvious to even the most junior web programmer.

But that wasn't at all obvious to Kate, and I should have known that would happen.

Basically Magicians

Developers, programmers, tech people in general (yes, including me) often forget that to all the people who don't work in the tech world, we are basically magicians. We take abstract ideas and turn them into concrete applications by using indecipherable texts and acronyms known only as "MVC" and "IDE" and "HTML". We are wizards using tools and laws that seemingly break the rules of physics and are seldom understood by persons who are not part of our "exclusive" club.

With that kind of power comes the responsibility to explain ourselves, clearly and thoughtfully, without resorting to name-calling or annoyance. Because, despite our myriad skills, varied experiences, and entirely different tech stacks which we work on daily, to the vast majority of people it's all just software. It's all the same.

This is the key thing that I failed to remember in my conversation with Kate. To her, to anyone who doesn't deal with these things on a regular basis, it's all just software. It's all 0s and 1s and true and false and math and colors and little buttons that won't do anything and links that don't open new windows unless you count to 6 and summon Beelzebub. It's all just crap that gets in the way of doing their job. If they didn't have to deal with it, they wouldn't.

Check Yourself

Kate and I eventually reached a point where we could solve some of her other issues with this system, and she felt pretty good about those agreements. We never got a resolution on the taskbar icon flash thing, and we never will. But eventually we got to a consensus where she understood why this was impossible, and can now go to her boss and try to find alternate solutions (like providing her teams with two monitors each instead of one). We got to a resolution, it just took a while.

We could have gotten there faster if I'd left my attitude at the door.

It is not the customer's job to know the ins and outs of our daily lives. It is our job to explain it to them, so they will know that we are not magicians but craftsmen, plying a trade and solving their problems with code. It is their job to explain to us what they want us to do, so that together we can work up a viable plan for getting their needs met. Both sides must do their part in order for anything to get done.

Nobody wants to play blame tennis; everybody just wants to find a solution. Leave your racket and your attitude at the door, and we can work it out together.

After all, it's all just software.

Happy Coding!

Explain Yourself!

A few days ago I was summoned to a meeting where one of the most basic ideas a web programmer can have wasn't obvious to our non-technical customers. Something had gotten lost in translation, and now I had to try to explain myself.

A mistranslated sign, reading

Our customers (let's call them Kate and Harold) wanted us to develop a web site that would allow users to type some answers into a questionnaire on a webpage, then take those answers and insert them into a PDF document that would be placed in their document database. We needed to keep these questionnaires for review later by our internal auditing group. All of this was completely doable, since we already had the PDF document template that we could insert values into.

While the programming group and the customers had had some emails being flung back and forth, discussing the various ways we could implement the system they wanted and the amount of time it would take, something just wasn't clicking for the customers. It should be said that this group of customers is very non-technical, and so they called a meeting to ask us programmers (specifically me, being the lead programmer on this project) some questions about the kinds of things we could do to implement this questionnaire system.

The meeting went pretty well for the first twenty minutes or so. Then, Kate started asking about what would happen when the content of the questionnaire changed:

KATE: So what would happen if we added a question to the questionnaire?

ME: Well, we'd need some time to work up a new template and add the question to the webpage.

KATE: That takes too long. Can't we set up the tool to allow us to just edit the webpage ourselves?

ME: We can certainly do this, but I'm not sure why you would want to. You want to be able to edit the questionnaire?

HAROLD: That's correct. We can incorporate changes a lot more quickly than we can now if we have this. How long would it take to set this up?

ME: Not too long I think, since we already a foundation for this kind of change in place.

KATE: Perfect!

HAROLD: Let's just be clear about this. You're going to enable us to edit the questionnaire, and the changes that we make will be in the document that is submitted to our document storage, right?

ME: ...That's why I said I wasn't sure why you wanted to do this. We can certainly enable you to edit the questionnaire on the webpage, but that doesn't automatically mean the changes you make will be included in the PDF document; we would still need to write some code to do that.

HAROLD: I thought you said you already had the foundation for this in place.

ME: We have the part that allows you to edit the webpage, yes.

KATE: So we will be able to make changes to the questionnaire?

ME: Yes.

HAROLD: I must be missing something. If we can modify the questionnaire, and you already have the foundation to do that, why does the programming team need more time?

ME: (annoyed) Because we still need to write code to make the appropriate changes to the PDF document.

KATE: But why do you guys need time to make those changes if you can already allow us to edit the questionnaire?

ME: (realizing the problem) Because the webpage and the PDF document are not the same thing.

Apparently this was news to them. It was not obvious to them that the webpage and the PDF document were not the same thing, that we programmers still had to write code to keep the webpage and document in sync. Further, I repeatedly failed to draw that connection and explain it to them, and just kept repeating myself using different words.

My immediate reaction was to be annoyed. Seriously, I thought, that's so basic! A webpage and a PDF document are OBVIOUSLY not the same thing! My annoyance faded quickly, though, because I realized that I was expecting non-technical people to know technical details.

Let's face it: customers don't give a crap about the code. All they care about is "click here, type this, submit that, done," and frankly that's all they should care about. I had incorrectly assumed that something that was obvious to me would also be obvious to them, and because of this assumption, I had failed to properly communicate to them the amount of effort it would take to implement the process they desired.

This miscommunication between technical developers and non-technical customers is a gap that I've seen a lot of programmers (including myself) fail to bridge: we're so caught up in the details of an application that we forget that not everybody knows what we know.

My old self, the one that was locked in an ivory tower, didn't see any reason to be able to communicate with customers. After all, that organization employed project coordinators, people whose job it was to communicate back and forth between the programmers and the customers, and I was perfectly happy to let them handle the customers' inquiries. It wasn't until I accidentally ran into one of these customers in the hallway (and utterly failed to explain to him what it was that I was doing) that I realized I should be putting more effort into my communication skills.

Communication skills are essential for programmers. I believe we should always be able to explain ourselves to both technical and non-technical people. At some point in our careers we will be placed in a situation where we need to explain our code and logic to a non-technical customer. If we can do this in a way that they end up understanding what we are saying without needing to know any technical details, then we've bridged the communication gap. If we can do it repeatedly, then we've become more effective at communicating than many developers out there.

And, hey, if you find yourself at a meeting similar to the one I was summoned to, maybe you'll be able to explain yourself better than I did.