Overpass Experiences The Eric Wroolie Blog

In love with our own lingo

I worked on a software project recently where the interface was developed more by developers than end-users (you see this a lot, actually).  In this instance, the application needed a phone number (but not a mobile number).  Rather than asking for a land-line number (or just “Phone number”), the entry form asked for a PSTN.  I was doing a usability review of the app and pointed this out-- “What the hell is a PSTN?”

The IT head pointed out to me that a PSTN is the industry term for a land-line (it stands for Public Switched Telephone Network) and that, now that I knew this, it should make sense to me.  I suggested he change it to “Phone Number”—since this app was going to be used by the general public.  He insisted that most people know this—just not me.  I told him he should still change it.  This advice fell on deaf ears, but we made some other good changes to improve the usability of the app.

photo credit: jakeliefer

My logic is (and continues to be)—if I don’t understand a term, it’s too confusing.  If I do understand it, would my grandmother?  In my situation, there are still occasions when I don't understand something because of cultural differences-- like expressions used in the UK but I never grew up with.  I still question them anyway.

This happens all the time—techies want to educate the non-techies on how to talk about technology.  Sometimes, these aren’t even terms in the technology industry—but acronyms and abbreviations used in a specific company that everyone adopts.  I’ve been in small twenty-person offices where you would think everyone went to school to learn how to talk like they do—even the secretaries: “Are you going to de-duplicate the NOC node or shall I?”  Eventually, no one knows how to talk like a regular person anymore.

We techies love our lingo.  In even smaller arenas (like a company or an industry) this lingo becomes even more precious. When we talk like this, we really sound like we know what we are talking about.  It impresses people (or so we think).  I can remember the feeling of working on a stock trading application for a major bank and talking about trade flips and different types of transactions and FSA systems and then stopping to reflect on how cool it must all sound—I was an insider.  I wasn’t a newbie—I sounded like an authority.

But all good software and hardware have the ability to take techie jargon and make it palatable to the masses.  A good site or web application should not imply when you log in that you have no business being there because you don’t know how to use it.  If you don’t understand the menu options, then you are in the wrong place.

In the future, people may look back at our gadgets today and conclude that Apple created the digital music player.  The truth was that portable MP3 players existed a few years before the iPod, but while techie ruled this area (with Rippers, LAME codecs, etc), Apple made the whole process simple for those who didn’t feel like pouring through thousands of forums and blogs to figure out who to rip a cd.  Try explaining to your grandmother how to set up a podcast aggregator while not using iTunes and you can see how much they simplified this area.  The term MP3 made it into the mainstream lexicon, but most of the terms of the early days did not.  Today, you still hear people argue about the benefit of Ogg or Flac over MP3, and can’t figure out why the mainstream hasn’t switched from MP3 to the superior Flac.  But the general public doesn’t care about this.

Google is revolutionary and I love the company, but to read many of the books out there (like “The Google Story” or “What would Google do?”) you would think that before Google, we were all randomly typing URLs into our browsers hoping to find something.  Yahoo, Ask Jeeves, Alta Vista, Lycos, etc were all there.  But Google made it easy in addition to being far more efficient.  One textbox, one button.  It was easy to tell your grandmother how to use it.

In technology, especially when it comes to interface design or anything that requires us to interact with the public, the best skill is to be a layperson.  Some people call this the “mother” test.  If your mother came to this site, or used your application, could she figure out how to use it without calling you?

I think about every time I have to fill in my tax forms how lost I am.  Even the “How to fill in this form” instructions confuse me.  It makes sense to someone, but they are in love with their lingo too.

The importance of reading books for software developers

I read a lot of technical books.  The last one I read was called “Design Patterns in C#”—it was good, but didn’t carry much new away from it.  I’ve read books on WCF, Silverlight, Ruby on Rails, and Java too – although I’ve never worked with these technologies in a professional capacity.  My hard drive is filled with demo projects.

photo credit: schoschie

I know professional software developers who have never read a tech book all the way through.  They survive on Google searches.  When they run into a problem or need to do something new, they Google, get the answer and move on.  This works, but you often don’t get all the of the information that would be helpful to you.

When you just search for the information you need, you only find the subjects that are interesting to you.  It would be like picking up a computer book and only reading the chapters that sound good.  You would look at the construction of the GUI, database code, etc.  This is how things like Code comments, html standards, testing habits, etc. get ignored so frequently in this industry.

When I conduct interviews for developers, I like to ask “What is the last technology book you’ve read?”  Sometimes, the interviewee will try to impress me by telling me how long he has been in the industry, but that’s not the answer I was looking for.  I also ask which websites or blogs they go to for new information—since books are slow to publish, but technology changes everyday.

You have to Google for solutions, don’t get me wrong.  But if you’ve read a book (or e-book or whatever) you have a more holistic view of a technology.  Google is fantastic because we don’t need to be so concerned with exact programming syntax as we do with what a technology is capable of.  Back in my early days as a software developer (VB5), I used to pride myself on my ability to write code on paper—I knew the exact syntax without intellisence.  Now, that’s just stupid—I can look up anything I need in a few seconds (because I know what I am looking for).

There is a fear that if you are carrying a book around about your specialist subject, you are somehow showing people that you don’t know enough about it.  I have a friend who gave me a hard time about reading a book on Advanced CSS a few years ago. He told me he had never read a programming book because they are too dry.  I’ll agree with that, but that’s like a professional athlete saying he doesn’t like to train because it is too boring.  By stepping away from the practice and into the theory of what we do, we become more self-critical and improve at what we do.

I listened to a Brian Tracy audio book years ago.  He is always talks about the importance of reading.  He says (and I’m paraphrasing):

If you went to see a doctor about a problem you were having, you wouldn’t want to see one that doesn’t read anything.  You wouldn’t want someone who had learned everything on the job.  Someone who is only really good at stuff he has done before and looked it up at the time.  You want someone who knows what is going on in the medical industry.  You want someone who reads the latest books and periodicals in his field.  The same is true for lawyers or any other knowledge profession.

And the same is true for software developers.

It only takes one error . . .

A good developer hates to see an unhandled error in his or her code.  If a user sees an error that tells them what line your code failed at, this is not only a potential security risk but also a major point of embarrassment.  Bad developers think it’s totally acceptable.

I have this kind of argument all the time-- “Why don’t you put an error handler here in case the calling code (or user) enters some bad data.”  I get the same response ever time, “But, how often will that actually happen.”  I have this conversations over and over.  The only thing that changes is the person I’m having the conversation with. 

When you’ve coded for lots of different companies, you start to learn how common this is. You have a few very dedicated developers who cater for errors I can’t ever see happening, but you get a lot who are just winging it and stop coding when their work reaches bare functionality.  When you see a news story about how a big site was hacked and all their data compromised, it’s not all that surprising.  A site can look very professional on the outside and be very shaky underneath.

I was trying to order some traveller’s cheques from American Express today.  You may have heard of the company.  I’m sure they spend top dollar for software developers. I’m still not sure what I did to get this (I wasn’t looking for bugs in their software), but I got a big ugly ColdFusion error message:

The error is a standard IIS-delivered unhandled exception error.  I know the lines of code that failed.  I can even click on a link to see a stack trace.  So, you know, I guess it’s embarrassing for the developer (or at least I hope so).  But the bigger issue is that I can’t trust the site any more. 

Somehow, I entered a zero where I should have had a value (and the code is trying to divide by zero), but I honestly don’t know where it was done.

Do you think I’m entering my credit card details after this?  I mean, what else are they not paying attention to?

Actually, it looks like American Express sent me to another site (with AmEx branding) called FX4You.  But still, it reflects badly on American Express.

The ugly truth of software development is that there are loads of standards, but not many of them are adhered to.  Testing always goes out the window to fit delivery deadlines.  Code reviews are non-existent in most organisations I’ve worked with.  The flip-side is that projects loaded with too much bureaucracy frequently fail to see go-live.  There is a happy medium and it is difficult to find.

Back in 2000, when everyone was going crazy about e-Commerce, I was working for a small company looking to build an online shop.  One day, I mentioned that I did not trust most websites with my credit card details, someone started to poke fun at me-- “Isn’t it ridiculous that our web developer doesn’t trust buying things on online?”  But, even then, I knew how easy it was to leave security holes open in software.  Just because I took precautions in my code, I knew not everyone else did.  Now it’s almost ten years later and I think most people are more wise to security, but I still would take a site that uses Paypal over a custom-built credit card engine any day.

Maybe I can buy my traveller’s cheques through the American Express site safely, but I won’t risk it.