Are You Changing the Rules of the Road?

I'm a regular jogger, but due to my travel schedule over the last six months, I'm no longer a member of a gym. That works out fine about 9 months of the year and whenever I'm staying in hotels, but if I'm at home during the winter, it gets a little brutal. That's why I've been out running like Forrest Gump this past week since the weather broke in Chicago and we've seen spring-like conditions all week. My favorite destination when I'm home is a small, nearby lake called Lake Arlington that is surrounded by a nice trail and thus a popular destination for walkers, joggers, and bikers.

The trail is quite uniform and there is a solid yellow line in the middle of it with room enough for two people walking side by side to be on each side of the yellow line. So, it's like a 4 lane road for people. Not surprisingly, people have historically behaved, by and large, as if they were on a road, with everyone usually on their right side and moving to the left to pass, when necessary. That all changed when there was a tragic accident a couple of years back, apparently.

I wasn't aware of the accident when it happened, but I do recall that last year when I came out for the first time to run, there were a lot of signs next to the trail and painted on the ground that changed the way things worked. Now, all bicycles and roller-blade traffic are supposed to go in the outer lane and all foot traffic in the inner lane. It seemed an odd change to me, but I do my best to remember where I'm supposed to be. Truth be told, though, I just accomplish this by always running around the lake in the same direction -- the direction that results in me being on the right side of the trail.

The other day, I was running out there, and I saw someone running at me in the opposite direction in the other lane (i.e. the 'wrong' lane which, confusingly, was her right lane). A lot of people probably don't bother to read signs on the pavement when they're walking or jogging, so she was probably just doing what she'd do anywhere else and following the common convention. A bicyclist coming up behind her was ringing the bell on her bike angrily, inasmuch as a chirping bicycle bell can be called angry. She was wasting her effort, however, because the jogger had headphones in. When she passed the jogger, she continued ringing the bell angrily while turning around and gesturing at the lane markers on the ground. I understood what she was getting at; the other jogger probably just thought that she was a lunatic.

Jogging, while refreshing, is extremely boring, so I spent the next 15 minutes or so contemplating this exchange and thinking about how it relates to my life and the world of programming. Was the unusual reconfiguration of the lanes a good choice? It's entirely possible that a far better urban planning mind than mine went to work on how to structure things following this accident. It's also possible that they changed things just for the sake of change to give a grieving widower some comfort. But whether or not it's a good idea, it's confusing because it runs completely counter to an established convention. What I couldn't convince myself to agree with was the anger directed at the jogger, since anyone new to the lake is setup to get it wrong by default.

What I realized is that the parallel thing that I talk about and coach people on in the programming world is the "Principle of Least Surprise." This is the idea that, all else being equal, system designers should aim to minimize the users' learning curve by incorporating patterns that they already understand. To drive the point home, consider a counter-example. Imagine if I designed a web application where left-clicking on buttons did nothing, and only right-clicking allowed you to activate the buttons. Would you be any less enraged and frustrated (or at least confused) at this web app if I told you afterward that my way actually made a lot more sense or, even, that it was done in response to some kind of problem or tragedy?

This holds true in and around software, and it holds true now more than it ever has before. Users don't expect to read instruction manuals -- they expect the things they're using to be discoverable. This is true whether they're using an application you've written or whether they're hacking through your API with Intellisense. This doesn't mean that you can't introduce new usage paradigms, but it does mean that you have to be clever and deliberate when doing so, in order to bring them along. There is an implied expectation from your users that you will delight them while not confusing them, even if not confusing them means compromising on what you believe the optimal solution to be (at least at first).

So when building applications or APIs, think of your users. When they fire up your app or call that first method on the code base, do you want their instincts to put them immediately in the correct jogging lane, or do you want them to be befuddled by random people shaking fists at them? Your urban plan may be the most safe, state of the art, wonderful thing ever conceived, but all of the joggers are going to head for the lakes where they understand how things work and no one yells at them.

This is guest blog post by Erik Dietrich. Erik is the founder of DaedTech LLC, also an experienced programmer, software architect, team leader, coach, and technologist that enjoys working with a wide variety of programming languages, frameworks and tools. The majority of his recent experience has focused on the .NET framework, though over the years he has worked with C++, Java, and a number of other languages. Projects range from low-level driver and kernel module programming all the way up to user interface design, and the types of applications run the gamut from home automation to rigorous code analysis to line of business applications.