def euler(x); cos(x) + i*sin(x); end

So there I am, peacefully logged into my US Bank online account. Everything is going well. We’re having a nice dialog. I click, it responds. I click… now I’m looking at a plain, white page with the following scrawled across the top in courier font:

an exception occurred: Unable to complete your request at this time, ReferenceID = “wl26*2006-71-59-03:21:11:742*XLP3-594861”

Imagine what the scene might be if I were speaking to a human teller and suddenly in our interaction I received a response like this. I imagine the likes of a scene from the Exorcist. The breakdown in the expected flow is extreme.

On the one hand, US Bank is not a little entity. They have plenty of money for technology solutions. On the other, I understand that exceptions occur. Here’s a gentle reminder to degrade gracefully and if you can write something to the screen, make it useful, somewhat reassuring, and perhaps apologetic. There’s no good excuse for barfing your undigested exception in my face.

I have been rescued from mundane obscurity. Yesterday I met with Robby and Allison and we settled on Interaction Architect as my title. Those are certainly big shoes to fill, boats really, but I’m looking forward to it. The title is broad enough to encompass interaction as it applies to humans-computers, humans-humans, and computers-computers. It’s both justification and impetus to push my knowledge and understanding. For example, with Project Borat, we’re focused on how we can facilitate client interaction throughout the project as well as pushing the envelope with features to support user interaction.

My interest in languages dates at least as far back as about 6 years old when I discovered Chinese writing. I was fascinated to the point of drawing nonsense characters for kids at school, telling them I could write Chinese. This interest extends to programming languages and mathematics. And since first working with one of the early Macintosh computers almost 20 years ago, human-computer interaction has been a persistent curiosity, if somewhat sidelined. In fact, design interests me more than coding, but unfortunately, I don’t possess abundant artistic talent. For me, interaction design allows me to straddle that space between visual design and implementation and I’m excited to further develop these skills along side the other highly talented folks at PLANET ARGON.

Yesterday, Project Borat and I were formally introduced. I’ll be the lead developer, picking up the thread and, along with Robby, I’ll continue to entertain you with insights we gain as we delve deeply into the process, knocking some moss off a few rocks and uncovering ideas that will work well for us and our clients.

As this project is just getting under way, one of the first things we’re facing is… hmm, I hate to label it because along with that label comes all sorts of assumptions. Sure, we could call it requirements gathering, but that doesn’t tell the whole story. Then there are stories, use cases, method XYZ, and better mention PQR for completeness. Before you run off googling those last two, I made them up. Point is, even though there is a lot of material on processes, and I’m learning more every day, it’s just not that simple.

So, today Robby and I took a quick jaunt over to one of my favorite places on the planet. How cool to work this close to Powells Technical Books. While he’s deep into today’s acquisition, Mastering the Requirements Process, 2nd Ed, I had my own surprise waiting on my doorstep this evening.

That brings me to one point about gathering requirements: the first value listed on the agile manifesto–“Individuals and interactions over processes and tools”. I’m guessing there’s more than a few reasons why that one is listed first.

Clients are people with varied backgrounds. If we are slaves to a particular methodology, we either 1) talk over the client’s head with unintelligible jargon, 2) try to coerce the client into “learning” our methodology so we can “be on the same page”, or 3) continually translate, in the back of our heads or on our notes, what the client is saying into our method’s jargon. The first two are disrespectful, the last one error prone. (Where’s the feedback that must occur for checking understanding?)

When we, as developers, began focusing on user-centric design and usability, it was a recognition that users deserved respect and need not be rescued, if you will, by our bright ideas. In a big way, we needed to keep our bright ideas out of the user’s way. In the same way, I’m not convinced I should expect a client to care about stories, use cases, or XYZ artifact. I do believe my role is to facilitate a client’s understanding of what they want and capture that as faithfully as possible.

I think plain ol’ natural language is probably the most valuable tool for that. “Ee gads, but natural language is fraught with ambiguities, imprecision, double meanings, and all things evil,” you say. Well, perhaps. But consider this: mathematics is probably the most precise form of “language” humans have yet devised, and plain ol’ natural language suffices to convey mathematics given a couple rules of usage.

First, we do try to eliminate ambiguity and imprecision with definitions. If I’m talking about a metric space, I begin with, “given a set X and a metric d, (X,d)”. There, no more ambiguity. And second, economy; introduce a symbol or name to mean a particularly well-defined concept. Add a dose of discipline, be conscientious about usage, and you can get very far using normal language to discuss very difficult concepts. Trust me, or visit a math class and watch people learning math.

So, that’s the first of my explorations. How far can natural language take me before I start reaching for this or that “representation”? I’ll aim to keep these posts short and pithy in the future, but thanks for ambling along with me on this one.