Coding Horror

So I had a few bandwidth issues recently, which you can see in the six-month alexa traffic graph for this domain.

There wasn't much I could do about the traffic spike. But I did make good use of two of my favorite tools for quick and dirty internet connection troubleshooting. The two most important questions to ask are:

How wide is your internet connection?

In other words, bandwidth. How many kilobytes per second does your ISP allow you to transmit and receive? Most consumer internet connections are highly asymmetric-- they offer extremely fast downloads but only a tiny fraction of that for uploads. Your typical cable modem is around 300 kilobytes per second when downloading (sometimes even faster), but only 30 kilobytes per second when uploading.

For quick bandwidth measurements, I like NetMeter. It only shows traffic on a single computer, but when run on a server it can give you a nice idea of how much bandwidth you're using at any given time. For such a lightweight little applet, it also has some surprisingly sophisticated long-term logging and reporting abilities-- you can see how much bandwidth you've used over weeks and even months.

How fast is your internet connection?

In other words, latency. How quickly does your ISP get your packets from point A to point B? Do they arrive in a timely fashion? Do they arrive at all? Unless your connection suffers from severe packet loss, this is a bit less of a priority than raw bandwidth. But it can be frustrating if your connection isn't responsive or is unreliable.

For latency measurements, I like PingPlotter. It comes in a few editions, including free. To test for latency or connectivity problems you'll want to run a few instances of PingPlotter over a series of days, all pinging large websites.

Set the graph interval to something wide like 24 or 48 hours, and once you collect enough samples, you'll have a nice idea of when your ISP's network is busy or unavailable:

Now, these are intentionally lightweight tools. They're no match for fancy, dedicated networking diagnostic apps. But they're simple to use and easy to gather data with. When you're calling your ISP's tech support, having these kinds of graphs to email them carries a heck of a lot more weight than generic complaints about "slowness".

A recent Scott Hanselman post described a problem he had with Windows Defender:

Defender was unable to update my signatures, instead throwing a COM-ish 0x8024402c. Others are getting Error 1609 and still others 0x80240022.

This isn't an isolated incident. The latest release candidate of Team Foundation Server also returns error codes during install:

Most of my installations of TFS have been pretty straight forward. However, certain instances where my installation failed, I would get weird, cryptic error messages. For example, one common error I keep getting when trying to install TFS on a certain server configuration is:

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 26105.

Can anyone decrypt this error message? I've seen this error so many times that the number 26105 is now tattoo'd into my brain! Looking at the log files helped me pinpoint the error, but I still couldn't figure out the problem.

I thought error codes went out with 8-bit computers over a decade ago. Is it unreasonable to expect human-readable error messages instead of undecipherable error codes in the year 2006?

Allow me to channel Alan Cooper's classic About Face for a second, because here's how users see that error code dialog:

It really isn't that hard to build a decent error dialog. Just try to communicate like a human being instead of a computer. Alan Cooper provides these three guidelines:

Be Polite
Never forget that an error message box is the program reporting on its failure to do its job, and it is interrupting the user to do this. The error message box must be unfailingly polite. It must never even hint that the user caused this problem, because that is simply not true from the user's perspective. The customer is always right.

Be Illuminating
The error message must illuminate the problem for the user. This means it must give him the kind of information he needs to make an appropriate determination to solve the program's problem. It needs to make clear the scope of the problem, what the alternatives are, what the program will do as a default, and what information was lost, if any. The problem should treat this as a confession.

Be Helpful
It is wrong for the program to just dump the problem on the user's lap and wipe its hands of the matter. It should directly offer to implement at least one suggested solution right there on the error message box. It should offer buttons that will take care of the problem in various ways. If a printer is missing, the message box should offer options for deferring the printout or selecting another printer.

Error code dialogs go 0 for 3: they're rude, unhelpful, and about as illuminating as a mineshaft. This is one scenario where it's easy for us to write better software than Microsoft.

A dialog presenting an error code is utter and complete failure. Don't ever use error codes.

I have nothing against World of Warcraft, but the Gamasutra editorial World of Warcraft Teaches the Wrong Things highlights one problem I have with the entire MMORPG* genre:

[WOW teaches players that] investing a lot of time in something is worth more than actual skill. If you invest more time than someone else, you "deserve" rewards. People who invest less time "do not deserve" rewards. This is an absurd lesson that has no connection to anything I do in the real world. The user interface artist we have at work can create 10 times more value than an artist of average skill, even if the lesser artist works way, way more hours. The same is true of our star programmer. The very idea that time > skill is alien.

Nothing demonstrates the massive disconnect between time, skill, and value better than ProgressQuest. My character SuperWumpus is on the cusp of level 86:

ProgressQuest does away with all that tedious gameplay grinding and lets us focus on what really matters-- levelling up. The game's Latin motto is quamvis progressio, which means "as much progress as you please." To further emphasize the point, the logo is two crossed swordsprogress bars:

You're fighting with time: the person who "plays" the most ProgressQuest wins.

This is something that the Pragmatic Programmers warn us about on slide 46 of their How to Keep Your Job presentation, which is about becoming a better, more deeply skilled programmer:

The EverQuest Syndrome is the same problem highlighted in the GamaSutra article: just because you spend a lot of time doing something doesn't mean you're doing it well. Here's a good example from Weinberg's The Psychology of Computer Programming:

Using this sort of measure, we can easily fall into believing that the worst programmers are the best-- because they work so hard at it. A case in point was a programmer who worked 14 hours a day, seven days a week, for eight weeks to get a small program running in a new installation. For his efforts, the company gave him an award for exceptional service. Shortly thereafter, another programmer (the first had been promoted to a management position as an additional reward) was tasked with making some additions to this program. He found that the program was such a confusing mess that it was easier to rewrite than modify.

The rewriting and debugging took exactly one week, working normal hours. Even considering that writing a program for the second time is far easier, the difference is significant. Moreover, the new program ran eight times aster, took half the storage, and was half as many lines of code. Clearly, the first programmer had been rewarded for making a mountain out of a molehill. The discovery of this misapplication of management largesse led to a severe drop in morale.

If you want to "level up" in your IDE, you can't do it by grinding through all-nighters. You have to build your skill portfolio.

* I searched for this link and one of the top hits is this Wikipedia is a MMORPG article. I've often thought that online forums were, in essence, multiplayer games.

Discussion

Pop quiz, hotshot. What do these toolbar icons do-- and what application are they from?

Okay, maybe that's a bit too monochrome. Does color help?

Okay, let's try something less abstract. Does a more traditional look help?

So we can see there's some kind of VCR-like functionality, and some arrows. And Furrygoat's Law is at work, because I smell some RSS in there.. somewhere. Perplexing.

I think you can see where this is going. Sometimes, the best icon choice isn't an icon. It's a word. Jef Raskin explains in his book The Humane Interface:

Icons contribute to the visual attractiveness of an interface and, under the appropriate circumstances, can contribute to clarity; however, the failings of icons have become clearer with time. For example, both the Mac and Windows 95 operating systems now provide aids to explain icons: when you point at the icon, a small text box appears that tells you what the icon stands for. The obvious reaction, which I have observed repeatedly when users first see this facility, is-- why not just use the words in the first place?

Instead of icons explaining, we have found that icons often require explanation. If you wanted to obscure or to encode an idea to keep it from prying eyes, substituting icons for the words might not be a bad start. The problem with icons can be considered an issue of diminished visibility: the interface presents an icon, but the meaning of the icon is not visible, or it may give the wrong message to someone for whom the graphic is unfamiliar or has a different interpretation. For example, an icon that shows the palm of an upraised hand indicates "halt" in the United States, but signifies "here's excrement in your face" in Greece.

Now take a look at this alternate, ultra-minimal toolbar skin:

Which of these toolbar skins would you rather use?

I'm not proposing that all icons be replaced with words. Of all the user-created toolbar skins on this page, the best are invariably a combination of icons and words. Graphics alone isn't enough.

Consider Microsoft Word with all possible toolbars visible:

Which of these toolbar buttons are decipherable to you? My eye is inexorably drawn to the toolbar buttons with icons and text. The rest are lost in a morass of 16x16 graphics noise.

It's experiments like this that convince me the Office 12 UI team is really on to something with the ribbon. Even the traditional menu seperators are plumped up with text now.

Microsoft recently released a complete set of C# code snippets for Visual Studio 2005. This brings C# to parity with VB.NET, which had many more code snippets "in the box".

Unfortunately, Microsoft's installation strategy for these new snippets leaves a lot to be desired. You can download and "install" all the snippets at once, but you must manually add each of the snippet folders via the Snippet Manager (Ctrl+K, Ctrl+B). I loves me some snippets, but this is unacceptable!

The snippets themselves, of course, are just individual XML files that end in .snippet sitting in a bunch of folders. There are two valid snippet paths: per-user and system-wide. The system-wide C# snippet path is:

C:Program FilesMicrosoft Visual Studio 8VC#Snippets1033

There's an index file in that folder, SnippetsIndex.xml, which appears to store the snippet paths. You might think editing this file would cause the folders to appear in the snippet browser (Ctrl+K, Ctrl+X). Seems logical, right?

Unfortunately, it's not that easy.

I think that file may be used the first time the IDE is initialized, but edits to that file don't appear in the Snippet Manager.

The real snippet paths are stored in the registry at:

[HKCUSoftwareMicrosoftVisualStudio8.0LanguagesCodeExpansionsVisual C#]

Why they chose to store this stuff in the registry and in an XML file is beyond me. Anyway, I packaged the correctly pathed snippets and a registry file together. Now you can quickly get the snippets installed on your system without running a pointless installer that does virtually nothing for you.

You can go from tired ..

.. to wired ..

.. in no time at all. If you've forgotten the keyboard shortcuts for snippets, revisit my snippet blog entry to refresh your memory.

Microsoft provides 295 new C# code snippets, and they're 508 KB in total size. I chose to package the snippets as a 7zip file for compression efficiency:

• ZIP: 229kb
• RAR: 73kb
• 7Zip: 56kb

To be fair to ZIP, it probably would have done better if the format supported solid archiving for this set of small files.

To decompress the archive, I recommend switching to WinRAR if you aren't already. It supports 7zip as well as RAR and ZIP, but more importantly, it won the best archive tool DonationCoder roundup. I'm not a huge fan of the UI, but I encounter RAR files often enough that WinZIP isn't cutting it any more.

Download C# snippets and registry file (60kb 7zip archive)