How can you screw-up creating an electronic version of an existing sign?

Here’s the offending item:
It’s a replacement for a combination of magnetic labels and hand scrawled messages that convey the current state of each of the London underground lines. They’re generally one of “good service”, “minor delays”, “severe delays”, or “oh no, you’ll never get to work”.

For the majority of people, their only interaction with this system is walking past, early in the morning, when they’re not at their sharpest, and trying to figure out if their tube line is working. As such, if there was a magnetic label stuck on your line, you knew things weren’t good. Given the lines themselves are colour coded, it’s easy to determine which line you’re interested in. Bear in mind that people aren’t going to get closer than about 2 metres to the board.

And herein lies the problem: by replacing the analogue board with a digital version, it’s no longer possible to ascertain by the physical presence of a label or writing, what state the line is in.

Let me say that again. It’s virtually impossible to tell, even from relatively close, if there are delays. Take a look at that screenshot (dodgy quality as it is) and see if you can tell which line has “minor delays”. Yeah, not easy is it? Now try doing that as you’re briskly walking past at 7.46am.

Underground line status (detail)

I’m surprised that they’ve relied solely on text and haven’t used any other means of distinguishing the significant information. Some other things that could’ve been used:

• Colour (of the text itself, the background, or some indicator. Need some inspiration? How about taking a look at something way out there, like, say, traffic lights)
• Size
• Weight (using font weight to indicate relative importance)
• Icons (or some other kind of visual indicators, nothing flashy)

I’m sure there are a whole load of advantages to having this digital system; most notably that it’s connected, and can be automatically and centrally updated. If only they’d spent any time on thinking about how people were actually going to use it!

Harry Beck would be turning in his grave.

A quick google reveals some of the funny, interesting and downright weird things that people have compared programming to. Let’s take a closer look at some of them…

The Classics

“Programming is like sex”
The most common version of this is, of course, that “One mistake and you have to support it for the rest of your life”. Very true. Unless you can manage to change jobs every six months, and then it’s more like “You can have lots of fun and then leave somebody else to clear up the mess”. There are lots of other variations too, including the controversial: “Sometimes you have to pay a lot of money to get someone who’s good at it”.

“Programming is like LEGO”
Hmm. As far as I can see this just means that, yes, you can put the pieces together in any way you like, but nothing you make will look quite as good as the thing you make by following the instructions. The impression of infinite freedom is an illusion. And if you’re not careful you’ll end up losing important bits down the back of the sofa or hoovering them up.

And, hang on, if it is like Lego, then how come we’re always talking about programming “glue”?

“Programming is like chess”
Not sure about this one. The biggest similarity I can see is that a lot of Russians are quite good at it.

Or maybe you could compare the interminably long games with the average duration of an enterprise software project? In fact, maybe having a chess clock would make pair programming more fun; you get 30 seconds to write a line of code before it’s the other’s turn.

The Outliers

“Programming is like Ice Sculpting”
What?! This has to be one of the most bizarre comparisons. I mean, yeah, it makes my hands really cold too. And my coworkers keep asking me why I bring that razor-sharp ice pick into the office on code review days.

“Programming is like a dream”
Unfortunately sometimes it’s like a really bad dream, the kind that you get from falling asleep on your keyboard during your afternoon sugar-low, dribbling on your mouse and getting an imprint of the enter key on your forehead. The kind where you wake up screaming after a nightmare about finding a bug in a 600-line long function with one-letter variable names and no comments. Only to find it’s not a dream after all, but where you will spend the majority of your waking hours for the next six months.

But of course, it can also be the kind of dream where you’re so far in the zone that you feel like you’re flying, effortlessly gliding over the terrain, appreciating the bigger-picture before swooping down into the details and watching how everything meshes beautifully together. Ahhh.

But it’s probably not the, erm, y’know, other type of dream.

“Programming is like an adventure game”
Yes indeed. I often find myself having to go back over ground I’ve already covered, in order to perform repetitive and mundane tasks purely so I can level up (I think it’s known as “getting promoted”).

Sometimes I think that compiler writers treat their error messages as some kind of sadistic text-based game:

You are in an open field west of a big white house with a boarded front door. There is an unterminated string constant to the west, and an undefined external symbol to the east. There is a header file on the floor in front of you.
> include header
You include the header. You are in a forest with incredibly long STL error messages all around.


On a serious note, I think part of the reason programming is so difficult to pin-down is because it requires such disparate skills; a combination of creative, intuitive right-brainedness and the logical, analytical left. People can take a lot of different things away from it depending on where they start from.

Anyway, that’s my selection of gems. Got any other interesting ones?

But what they seem to have missed is that something very different, but equally significant, has replaced it: the instantaneously-shared TV experience, enabled by Twitter. With the omnipresence of laptops, broadband and Twitter, the sofa’s now connected. It’s possible to sit at home on your own and discuss, berate and dissect whatever’s on RIGHT NOW.

Most of us have experienced shared TV viewing at some point in our lives. People my age would’ve probably sat in the living room with their parents, before every kid over the age of 6 got a TV in their bedrooms. Shared living, like student accommodation, is also a common way to experience it. As we get older our social circle tends to shrink, and television watching can become a more isolated affair.

Of course, the “old” ways of discussing TV still exist; we still enjoy vitriolic printed reviews in books, newspapers and magazines, we can still call someone and discuss a program over the phone. But these off-line methods are bandwidth-limited (we can only call one person at a time), slow (with a lead time of days or weeks for printed media) or uni-directional. Fundamentally, they lack immediacy.

In contrast Twitter enables us to connect with lots of people simultaneously; lots of people who are all sharing the same TV experience. It’s like having a load of sarcastic, funny mates in your living room. Ones that you can get rid off just by closing a laptop lid.

I’ve identified 5 major groups of TV twitters:

Schedulers
These helpful individuals post tweets about things they find interesting and are intending to watch themselves, normally along the lines of:
Guy Richie's Revolver is starting now on Channel 5 - the most confusing film I've ever seen!

The usefulness depends on the type of people you follow and on where in the world they are. @aplusk and @courtneylover79 are not going to be posting much about what’s on BBC 1 on a Sunday evening.

Crowds
This accounts for the vast majority of people twittering about telly. They tend to congregate around large “event” programmes, Eurovision, Derren Brown, X-Factor etc, or geek-oriented watching such as Charlie Brookers recent (and excellent) Gameswipe. Of course any reality-TV type programme presents significant opportunities for Twitter-enabled sniping. We all know how much the internet loves this kind of “look at that!”, “lolwut”, “OMG!”, “loozer” stuff, but it’s often combined with genuinely funny material too.

Hangers-on
This groups consists mostly of spammers, and people outside of the country where the program is being broadcast. They spot trending hashtags and either piggyback whatever they’re selling onto it, or tweet something along the lines of “What the hell is #nnn…?”. They don’t add much. Enough about them.

Celebrity Friends
If you follow celebrities* – and lets be honest, who doesn’t? – the chances are they have some friends. And celebrities friends are quite often celebrities themselves (keep it in the family, eh?) so you’ll often see tweets like:
my friend on bbc2 newsnight right now! go sister!


Try to contain your excitement. Unless it’s you of course, and then you’re welcome to tweet OMG!1!! I'm on TELLY!!
(* of course, by celebrity I mean anyone with more than 500 followers).

Commentators
Some twitterers take it upon themselves to provide blow-by-blow, often eloquent and vaguely fantastical coverage of certain programmes. This can feel like having someone on LSD on the sofa next to you whispering in your ear. So probably not for those of a sensitive disposition.
Gregg keeps saying "I would happily eat that." To be fair, he would happily eat an old Big Mac out of a tramp's shoe.

This type of companionship can brighten even the most mundane viewing. It tends to be the product of “resting” writers or comedians, writer\comedians, or comedian\writers.

Will TV ever be the same again? For me it won’t.

(The @names have been changed to protect the innocent. Well, some of them…)

1. Exclamation marks in dialog box messages
Look, it’s probably the 50th time I’ve seen this message today. The fact that this application “Cannot connect to database!” is no longer a surprise. You may have noticed that most professional software uses a neutral tone for its communication with the user. Try that. Also:
1a. Double negatives in confirmation dialogs
“Are you sure you don’t want to lose your changes?” Err… what? No. I mean YES. Oh sh*t. Any dialog that requires you to stop and try to parse the question in order to work out if you’re about to destroy several hours of work is not doing its job. It’s getting in the way of you doing your job. In fact, convoluted messages are such a serious issue that Microsoft even tried to help developers to help their users by introducing a whole new kind of dialog box in Vista: the question/task dialog. Good luck with that.

2. No tab ordering defined\mouse only navigation
Because no-one’s ever going to use the keyboard to navigate the zillion controls in your data entry app, are they? This one actually surprises me, because I’d have thought that developers would’ve needed to navigate quickly through the application while they’re writing it. Well, that doesn’t seem to be the case. Pretty much all commercial apps are good counter examples. I don’t mean to hold up Microsoft Office as a paragon of UI virtue, but they definitely do the “alternate way of navigating everything” thing well. Everything you need can be reached by both keyboard and mouse. Unplug your mouse and try that with your favourite piece of in-house software and see how you get on.

3. Group boxes around everything
This is a bit of a WinForms specific one. The clue is in the name: group boxes are for grouping logically related controls, not for providing a kewl recessed border around every single one of the controls in your dialog. Don’t kid yourself that this is doing anything other than using up some valuable screen real estate. (See if you can spot another pet peeve in the example dialog, too).

4. Icons created in the IDE
Look, Visual Studio’s a really good integrated development environment, but it ain’t no Photoshop. Don’t try and use it to create icons. And while you’re at it, please don’t make icons consisting solely of the name of your application (inevitably an acronym) in pixel font and primary colours. Oh, and don’t just steal various icons from another application, unless you’re going to steal the whole lot; one of the key visual aspects of a good UI is consistency. Mixing your hand-drawn 4-bit icons with the glorious 32-bit shiny ones you borrowed is going to be jarring. In fact, why not go the whole way and get someone who can actually draw to create your icons for you? After all, you wouldn’t have someone who wasn’t a programmer writing the code, would you…?

5. Data grids
Otherwise known as the “Excel is the pinnacle of user interface design” disease. Break the habit. Generally, the more types of controls that are embedded in your grid, the less likely that it’s the right kind of interface paradigm. Yeah, I’m looking at you, person embedding a calendar control, drop down box, graph, slider and checkbox in each row of a data grid. And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.

6. Not implemented message boxes
Ahh, the GUI equivalent of source code TODO comments. Of course, it’s an in-house software give-away; no commercial (desktop) software would be brazen enough to ship with bits of functionality dangling from the stumps of buttons and menu items. Would it? Feel free to provide counter-examples if you have them.

7. Excessive use of dialog boxes
Warning: dialog boxes are considered harmful (to usability). They’re the equivalent of restraining your user by force and preventing her from moving until she answers your question. That might be OK for matters of life or death (i.e. data loss), but not otherwise. Every time you find yourself about to add a new message box, stop, take a deep breath and consider whether it’s really necessary.

So, if you’re a victim or one, many, or all of these user interface faux pas, all I can say is: sorry. I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins.

Why? Well, because it’s too easy to use them as an excuse for not defining your shared library interfaces properly.

The reason this is on my mind recently is that several hundred, yes, you heard that right, several hundred DLLs have been released by my group over the last, ooh, 10 years or so. They are all still in use. Each of them has burned into it a copy of the library that deals with interfacing with Excel. That means each of these has it’s own little internal copy of the current state-of-the-art. The problem with that is; the state-of-the-art moves on. And how do you go about updating the DLLs that are already in production? You have to re-release them. In an environment where thes DLLs are used for marking the profit and loss on a large derivatives trading book, that’s not a small undertaking. And it’s made worse if, say the DLL in question was last released with a different version of the compiler.

My approach would be to refactor this shared static library (.lib) into a stand-alone DLL.

At this point, people start saying “oh, but then you’ve got a single point of failure, if you release a broken version of that DLL, everything will stop working!”. Not exactly a compelling argument. If the functionality of the DLL is well defined, and there are well known entry points it should be easy to put together a comprehensive black-box test suite. In fact we already do that with all our other DLLs (COM servers). The fact that this shared library *isn’t* a DLL has meant that it’s fallen through the testing cracks; another good reason to refactor it.

The internal interface to the shared library is already relatively well defined. It has a set of header files that define all of the functions and classes that are consumed by others. It’s a relatively small step to compile it as a DLL, rather than a static library. The problem then becomes one of maintenance, dealing with the inevitable changes to the external interface in a backwardly compatible way.

And that’s the problem. It requires some effort. Elsewhere in our codebase we use COM as a magic cure-all for avoiding having to deal with versioning: interface immutability rules. All interfaces are public, no published interface ever changes, object identity is based purely on interfaces supported. If you haven’t got these crutches to rely on, then you have to enforce the rules yourself, which can be both logistically and technically difficult when you’re dealing with C++.

But it’s not impossible. And I really think it would be better than having hundreds of DLLs all containing subtley different versions of the same code, and being unable to change behaviour across the board without having to build, test and release them all.

Maybe you’ve got a different opinion?