Designing for what software could do to you

When I am driving in the car Karen is usually with me. She provides good guidance, telling me when and where to turn. Sometimes though I push her buttons and she really tells me where to go. She has accompanied me in Ontario, British Columbia and New Bruinswick and has been a great help. Karen is of course the name associated with the female Australian accented voice on my Garmin GPS. I flew into Montreal this week after a 2 hour flight delay initiated by the A310 “computer problem” that caused us to switch aircraft, to arrive at the Avis counter where due to yet another “computer problem”, they had no cars available for their customers with reservations. I ended up renting a new Jeep Commander from another agency and fortunately it had a GPS built in. (I had very errantly neglected to bring Karen with me to Montreal) After attempting to enter in my destination and failing, the helpful agent informed me that the address I had was not Montreal, but Ville St. Laurent. The address was incorrectly entered by some CRM “computer problem” in my email. Properly addressed in the GPS, I was off. Another unnamed female voice  guided me along for the first 20 minutes of my journey with accurate and infrequent hints as to my required turns. I then arrived in Ville St. Laurent and she lost her mind. She would with absolute accuracy tell me to turn left or right, the moment I had already passed the intersection. After 5 minutes trying  to outguess her or get on the road she had intended me to turn on, I powered her off and went back to the paper map and arrived very late. 

Oh… how I missed Karen.

Most IT consultants architect, design, build, test or support the people who make software and computers work. When computers and software fail, it’s probably in large part our fault. I wonder when we design software if we think too much about what the software will do for you and not nearly enough about what the software will or could do to you. I had the opportunity to work briefly with a Unisys subsidiary that focused on defence projects and specifically a targeting and fire control system. Engineering for safety was just a large a discipline for software development in that program, as performance, maintainability, quality, functionality etc. They knew that what the software could do to you was of critical importance. Perhaps the corporate and commercial world can learn something from that. Perhaps the designer of the GPS software in my Jeep Commander really should have added a routine or two that enabled it to say. “Hey, I’m having a bad day… you should really just pull over and look at the map”


This entry was posted in Technology. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s