ux

Thoughts On Bridging the “Lacuna Humana”

In my previous post, I discussed the semantic gaps that afflict current programming languages. These gaps are caused by tools focusing on syntax and parsing, and mostly neglecting human factors.[1] I’m not just talking about the fact that languages are clumsy for us to use (more about this later); I’m saying that they ignore our need to talk about important realities of software development: security, coding habits, testability, maintenance plans, dependency management, requirements, intellectual property, and much more.

All this stuff falls within our scope of concern, but none of it is describable in our languages. That’s weird. Imagine we hired a general contractor to build our house, and he was great at swinging hammers and leveling studs. But as soon as we asked him questions about building permits or hiring subs or choosing the right kind of concrete for the foundation, he acted like he didn’t have a clue what we were talking about. We’d be likely to end up with lots of false starts, poorly met requirements, endless kludges, tons of frustration, a heavy QA burden. Hmm… That sounds familiar.

I call this lack of semantic continuity the lacuna humana — the human gap.

The good news is, gaps can often be bridged.

image credit: vestman (Flickr)

I promised I would describe a bridge that has a lot of virtues, and I’m going to begin that work here. It might take us a couple posts to get all the way across, though. Thanks for hanging with me…

Continue reading →

Lacunas Everywhere

I’m told that in Czech, the word “prozvonit” means “to call a mobile phone and let it ring once so that the other person will call back, saving the first caller money.”

Image credit: AstridWestvang (Flickr)

How would you translate this word to someone in New Guinea who has never experienced electricity, let alone a telephone or a bill from Verizon? You wouldn’t. This is an example of a “lacuna“–a translation problem caused by semantic gaps in a target language. Lacunas occur in programming languages. You might know a few; maybe you wish C++ had python-style generators–or that Java had Haskell’s notion of pure functions–or that C supported PHP-style string interpolation. But what if I told you that semantic misalignment between any pair of programming languages is just minor details? What if I claimed that all programming languages I’ve used have numerous, pernicious, and expensive semantic gaps? That we don’t see these gaps for the same reasons that a stone-age hunter-gatherer fails to notice his inability to discuss patterns of cell phone usage? Would you think I’m crazy? Continue reading →

Add some more extra redundancy again

It’s the season for coughs and sniffles, and last week I took my turn. I went to bed one night with a stuffy nose, and it got me thinking about software.

What’s the connection between sniffles and software, you ask?

Let’s talk redundancy. It’s a familiar technique in software design, but I believe we compartmentalize it too much under the special topic of “high availability”–as if only when that’s an explicit requirement do we need to pay any attention.

Redundancy can be a big deal. Image credit: ydant (Flickr)

Redundancy in nature

Mother Nature’s use of redundancy is so pervasive that we may not even realize it’s at work. We could learn a thing or two from how she weaves it–seamlessly, consistently, tenaciously–into the tapestry of life.

Redundancy had everything to do with the fact that I didn’t asphyxiate as I slept with a cold. People have more than one sinus, so sleeping with a few of them plugged up isn’t life-threatening. If nose breathing isn’t an option, we can always open our mouths. We have two lungs, not one–and each consists of huge numbers of alveoli that does part of the work of exchanging oxygen and carbon dioxide. Continue reading →

A Comedy of Carelessness

Act I

The day after Thanksgiving I went on a long road trip to eastern Wyoming. Total driving time: about 7 hours, each way.

At a gas station about 2 hours from home, on the way back, my credit card was declined. Apparently, fraud prevention algorithms at my credit card company had decided that it was suspicious for me to use my credit card out of state. This was rather irritating, since I’d just driven 12 hours on this same highway, using this same credit card to fill up the car, out of state, 2 other times in the previous 24 hours.

Photo credit: herzogbr (Flickr)

I used an alternate card and finished my trip. When I got home, I called American Express to get the card unblocked. (The block didn’t just apply to gas stations in Wyoming–once suspicious, the company wouldn’t let me buy gas a block from my house, either.) I spent 5-10 minutes working my way through an automated phone queue. It asked for several pieces of info to prove I was, indeed, the card holder–all 16 digits of the card, the 3-digit code on the back, last 4 digits of my social security number, phenotype of my dog… I had to call back twice–once because a family member asked me a question while I was fishing my card out of the wallet, and the system lost patience waiting for a response, and once because I pushed the wrong key and had no way to backspace.

Finally, on my third attempt, I got to the concluding challenge in this interview with mindless software: “Enter the first four letters of your place of birth.”

I was flummoxed. Of course I know where I was born, but which place did they want? I didn’t know whether this question was soliciting a city name, a state name, a hospital name… I hesitated. I guessed that city name was most likely to be the answer I’d provided to this security question in the past, but I can think of one or two accounts where hospital or state is what’s wanted.

While I was biting my lip, the system rejected my answer, and I was back to square one. I called in again and remained silent until I got routed to a live operator. She unblocked the card and offered to give me a link to an app that I could download, to make it convenient for me to unblock my card whenever this happens in the future.

Well, sorry, American Express–despite your cheerful customer service representative, you did not make a happy customer with this experience. If you’re going to challenge me when I go out of state, Continue reading →

Book Review: Universal Principles of Design

A few months back, my friend Trev recommended this book to me. I’ve been digesting it one topic at a time, on my lunch breaks.

It is profound and fascinating reading.

This is not another software pattern book. In fact, it is not really software-centric at all. It describes truths about the way human beings perceive, reason, generalize, and communicate. Many of them have obvious application to UX, UI design, and to software in general. On the scale of profundity, it gets a 9 out of 10; I suspect that I’ll be blogging about insights from the book for months to come.

I think it’s important to look at familiar problems from new angles; many profound breakthroughs in science are attributable to cross-disciplinary insight. Though time spent in this book won’t directly hone your coding skills, it will help you see recurring problems and solutions with new eyes, and it will suggest tried-and-true criteria for evaluating design alternatives.

As a teaser, some of my favorite design principles in the book include: Interference Effects, Contour Bias, Horror Vacui, Uncanny Valley, Recognition Over Recall, Wabi Sabi, Satisficing, and Propositional Density.

For now, I’ll omit any definition of what these intriguing terms mean, and leave discovery as an exercise for the reader. :-)

Related articles