Thunderclap, the Newsletter of Rolling Thunder Computing

Volume 6, Number 1, Fall 2003

In this issue:

Feature Article: Brain Droppings. Nobody Asked Me, But ...

Blatant Self-Promotion: I'm a legend in my own mind, New in-house class on Web Services

New Book: FOURTH Edition of Introducing Microsoft .NET on the way

A Good Read: The Flashman  novels, by George MacDonald Fraser

Annabelle and Lucy's Latest

Subscription Information


Feature Article: Brain Droppings

I've chosen this title to honor George Carlin's book of the same name.

Nobody asked me, but ...

Common Sense Does Not Exist

Nothing on God's good earth is less common than sense. A company president of my acquaintance thought that her title qualified her as a web designer. When I looked at her site and asked how a viewer would navigate from this thing over here to that thing over there, she said, "It's common sense," even though I couldn't figure it out after 5 minutes of banging, when I should have a) been able to figure it out, instead of not, and also b) in a second or two, tops. "Well, you just didn't see it," she replied. "It's still common sense." 

When someone uses the term "common sense", they mean nothing more nor less than, "I think X. Therefore, by extension, everyone else in the world should think X too, because everyone else in the world thinks like I do."  Bullshit. What's obvious to you is obvious to you, and has no extension to anyone else. Your customers and readers don't give a flying fish what's obvious to you. You, on the other hand, care greatly about what's obvious to them, and it has no relation to what's obvious to you -- as I wrote in this space about a year ago in a rant entitled "Know Thy User, For He Is Not Thee" (click here to read it). Anyone who uses the term "common sense" hasn't learned that yet, including this company president.

Next time you catch yourself saying "common sense" (or "intuitive", which means the same thing), stop and listen to yourself for a second. You probably sound like an idiot, insisting that other people think like you do when you're arguing with them because they clearly don't. Replace that term with "I think", which is what you really mean. Then you'll realize that you need to find out what the other person actually does think, instead of what you think they think, or wish they thought. And that's an uncommonly sensible thing to do.

Why the Hell Doesn't FreeCell Have an Undo Key?

It's a crime against God and man. Every other game in the universe does. Why not this one? Longhorn, schmonghorn. Fixing this awful omission ought to be a far higher priority.

Spend the User's Hassle Budget Wisely

Security is such a major part of application design these days that you would think app designers would start learning to do it well. But almost nobody does, at least not yet -- see my screed entitled "Security Stupidity" (click here to read it) from a year ago. Very few people realize that the correct level of security in any particular instance is a tradeoff between usability and safety.  Most authors (Michael Howard and David LeBlanc, authors of Writing Secure Code from Microsoft Press, are notable and welcome exceptions) choose a point in the spectrum and argue that it is the One True Word. If you make your app too hard to use (requiring a password before opening every file, say, even if the user has already entered it once), users will dump your product, and you've wasted your time writing it. But if it's not secure enough, or users feel that it's not secure enough, then users will dump your product and you've wasted your time writing it. You need to avoid wasting the user's time and energy dealing with wrongly-placed or ineffective security at places that don't need it.

I've coined the term "hassle budget" to describe this problem. The hassle budget is the amount of security-related overhead that a user will tolerate in order to use your product. Use as much of it as you need to get the job done, but no more. You can see a clear example in the clock on the lower right-hand corner of the Windows task bar. If you double-click on it, you get the clock-calendar screen show below, allowing you to see the current time and date, and scroll forward and back on the calendar.

I find it very handy when I'm on the phone with prospective clients discussion future dates. I need to know quickly which day of the week is November 23, or conversely what date is a week from Monday, and this box tells me graphically and immediately. The problem is, however, that only administrators are allowed to see this box. My wife, for example, is not an administrator on our home system (God protect us from that). So if  I need to check a future date on her computer and try to bring up this box,  I get an annoyance message (I won't call it an error message. I didn't make any error. The stupid programmer who wrote this did.) saying "Only administrators can change the time." So to bring up my calendar, I have to go back to the start menu, pick Start -- Programs -- Accessories -- Idiocy -- Stupidity -- Hassle -- Chickenshit ... (you get the idea). Allowing only administrators to change the system clock is probably reasonable. But blocking a non-administrator user from even seeing the calendar and clock is just dumb. The data isn't that sensitive, I mean we're not trying to prevent users from knowing what the current time and date are, or even what date it will be next Thursday. A non-administrator user should be allowed to see the box, but somehow be informed that it's read-only -- maybe gray out the OK button, maybe an explanatory string, maybe an entirely different dialog box designed for display only. This designer has not spent the user's hassle budget wisely.

Once you've exceeded a user's hassle budget, they'll find a way to bypass whatever rules you've established, probably without distinguishing the wise ones from the stupid ones. (That's your job, no?) In the clock-calendar example from the preceding paragraph, users will make themselves administrators so they can see this box, thereby violating the Principle of Least Privilege (always run with the lowest level of privilege that will get your work done, so that if you do get hacked, the damage is less than it otherwise would be). Here's another, bloodier example: many years ago I worked for a company that made chaff radar decoys for surface ships and aircraft. We started with meter-long bundles of aluminized fiberglass strands, then chopped them to the half-wavelength of the radar we wanted to block (usually a few centimeters) using a power-fed press with a guillotine blade. To make this device safe to use, it had two safety interlock switches located far enough apart that the operator couldn't hold both of them with the same hand at the same time, and it wouldn't run unless both buttons were pressed simultaneously. The machine's designer thought (hey, common sense, right?) that this layout would keep the operators hands well clear of the blade. However, one particular user liked to smoke while operating the machine. (This was back in the days when people were allowed to smoke in factories). She made herself a stick with two tabs on it. She'd lay it down with one tab on each button, apply pressure with one hand, and smoke with the other. She got quite good at extracting, lighting, and puffing a coffin nail single-handedly. She felt that her hassle budget had been exceeded, and figured a workaround. I'm told that her prosthetic hand works very well, and even has a cigarette holder attachment. 

The Taxonomy of Acronyms

In the world of modern computing, it is essentially impossible to form a complete sentence without using an acronym of some sort, often more than one. The problem with the customary TLA (Three-Letter Acronym, like DLL or SDK. TLA itself is a TLA) is that there are only 17,576 unique ones in a 26-letter alphabet, and Microsoft used them all up last summer when the Whidbey project got into high gear. I don't know who first coined the term TLA, but I've coined a bunch more to solve this problem, and published them in various forums.  Enough people have asked me to summarize them that I've written the following table to help you keep them straight:


Stands For

Unique Combinations (26-letter alphabet)


And, of course ...


Three-Letter Acronym *



TLA itself is a TLA


Four-Letter Acronym Package



FLAP itself is a FLAP


Five-Letter Extended Acronym Package

1.18 x 106


FLEAP itself is a FLEAP


Six-Letter Extended Acronym Package, Eh ? (I wrote this one in Canada)

3.08 x 108


SLEAPE itself is a SLEAPE

* The construct that we commonly call a three-letter acronym really isn't an acronym if you pronounce all of the letters, as in "Tee - Ell - Ay". (Only one person has ever called me on this in my entire life). However, we can salvage the situation by renaming it a "three-letter abbreviation," if we actually give a damn. The others are true acronyms, though.

I Need Help On A Bug

I have a very strange bug with my Windows XP installation with the plug-and-play device driver recognition. I plug in a USB device (printer, scanner, smart card reader, I get the same problem with each one of them). XP recognizes it, installs it, and it runs correctly for the duration of that session. So far, so good. But when I restart the machine, the device is disabled. I can't print to the printer, scan from the scanner, or read from the smart card reader. The control panel still sees the device and shows it as present, but it doesn't work and any attempt to access it produces an error. To get the device to work, I have to unplug it and restart the machine. I then plug it in again, XP recognizes it, and it works properly for the duration of that session. It's as if XP was forgetting about devices from one session to another. The two obvious workarounds, leaving the machine running forever, or just unplugging and replugging every time, I find logistically prohibitive. I see the same problem on two separate Dell machines, one desktop and one notebook. Dell hasn't a clue. I haven't a clue, and can't find one on Google. Any of you readers ever see this, and how did you fix it? A Rolling Thunder Computing coffee mug to the first reader to solve the problem for me.

Platt's Third Law of the Universe: Logistics Trump Everything

My work with hassle budgets has led me to coin Platt's Third Law of the Universe. You no doubt remember my First Law: called Exponential Estimation Explosion, it states simply that every software project takes three times as long as your best estimate, even if you apply this law to it. You also know my Second Law:  "The amount of crap in the universe is conserved." So if you want less crap to deal with, you have to dump yours on someone else's head, often for a fee, because there's no such thing as making it disappear. My new Platt's Third Law states simply that "Logistics Trump Everything." It doesn't matter how beneficial or horrible something is. If it's easy to do, people will do it, and if it's hard to do, then they won't. Therefore, by extension, you should make good, smart things easy to do, and bad, dumb things hard to do.

The classic example of this was the checkbox on the old ATL object wizard that asked "aggregate the free threaded marshaler?" The FTM was never, EVER necessary, and almost always wrong and dangerous. It gained you a smidgen of performance in one specific, rarely encountered design situation. No one really knew what it did, in fact, I had to go back and check the book that I mentioned it in before I wrote this section. But because it was there, people often used it, and got themselves in all kinds of trouble and never knew why. The logistical ease of including it overrode the common-sense notion ("I think." See what I mean? I think it, but do I do it? No, and neither do you. It's might be sensible, but it sure ain't common.) that you shouldn't use something you don't understand. Before this wizard, knowledge of the FTM was buried deep in the documentation. By the time you burrowed down to it, you understood the environment that you were working in, so you had the vocabulary and background to understand what the FTM was and know when it was useful (seldom) and when it was wrong (almost always), and could use or not use it accordingly. It had no place on a wizard screen.

For another example, Web services in Visual Studio v1.0 and 1.1 are very easy to implement because there's a wizard to generate the project. Web services make all kinds of design sacrifices in order to make function calls across multiple platforms. They give up a lot of performance, and also most type and object fidelity. If you're communicating from one Windows machine to another, .NET Remoting is almost always a better choice. You get better performance (by a factor of 10 or more, see my book), better type fidelity, and a choice of activation models. It runs better and it's more powerful. But because there isn't a wizard throwing the choice in your face, almost no one ever does it.

So if you want something done often, make it easy to do. If you want it done seldom, make it hard.  Platt's Third Law: Logistics Trump Everything. You heard it here first.

How the hell do you throw away a trash can?

I've got one that the wheels fell off, and I'd like to get rid of it. But the trash men keep leaving it on the curb. I tried lying it on its side, putting a note on it (they seem to be illiterate, at least in English), even putting it inside another trash can. It's made of metal, so it's hard to cut up. What the hell am I going to do with this stupid thing? There's got to be some common sense solution. But if I can't figure it out, then it isn't common, is it?

We'll continue our discussion of  .NET and Web Services in the next issue. Give me a call if I can help you out. Until next time,  as Red Green  would say, "Keep your stick on the ice." 

Blatant Self Promotion: Would you buy a used car from this guy?

New Class on Web Service Enhancements

Recognize me? Microsoft is running a new promotion featuring me and a few of their other top independent consultants, calling us "Software Legends." We're doing bookstore events and other promotions, such as events at Tech Ed and PDC. Part of the promotion involved a professional photo shoot in Redmond. I'm astounded that the skill of the photographer, Karen Moskowitz of Seattle (, actually managed to make me look good. I've got posters available, suitable for framing or wrapping fish, and I'll mail you one if you promise to display it. Send me a photo of it on your wall (ideally without darts in it), and the best will win a prize. Here's what I'm up to: 

NEW! 5-day In-House Training Class on Web Services

The main article in this newsletter describes Microsoft's new extensions to XML Web Services that actually make them useful for something besides saying, "Hello, World." They security pieces, in particular, are well thought out. Web Services are now sophisticated enough to warrant a topic in themselves, so I've written a 5-day class to do just that. It uses Microsoft's WSE version 2.0. See the syllabus online here, then call me to schedule yours.

5-day In-House Training Class on .NET or .NET for Insurance

.NET is here, and it's hot. It changes everything in the software business, and you can't afford to be without it. Rolling Thunder Computing now offers in-house training classes on .NET, using my book as the text. I've split it up into customized offerings, such as .NET for Existing 3-tier Microsoft Programmers, .NET Framework Serious Geekery, .NET Web Programming, and .NET for the Insurance Industry. See the syllabi online here, then call to schedule yours. 

ACORD XML for Insurance In Depth 

Insurance carriers, learn ACORD XML from David Platt. This 5-day class will give you everything you need to know to jump-start your application development. Learn about security and plug-and-play. See the syllabus online here. It can be customized to your needs. 

New Edition: Introducing Microsoft .NET, Fourth Edition


Like idiots, Microsoft asked me to keep on updating my .NET book, and like a bigger idiot, I agreed. I'm working on the fourth edition (Whidbey beta) and fifth (Whidbey RTM). Watch this space for time and content announcements. 

A Good Read

Fans of historical fiction have reason to rejoice. Although they're not new (published between 1986 and 2001), I've recently discovered the Flashman series by George MacDonald Fraser. Those of you my age or older might remember Masterpiece Theater's presentation back in the early seventies of the classic Victorian novel, Tom Brown's Schooldays by Thomas Hughes. Fraser has taken the villain of that series, Harry Flashman, and spun him into every historical upwelling of that turbulent period. For example, he got caught in the Great Sepoy Mutiny in India, fought on both sides in the American Civil War, and rode with Custer at the Little Big Horn. The stories are told in the form of a first person memoir, looking back on his adventures from his old age, so it's not much of a spoiler to tell you that he's the only survivor of that last kerfuffle. He's a slimy rogue that you root for in the same way you root for Wile E. Coyote, with about the same result. If you think of a cross between Horatio Hornblower and Black Adder, you'll have about the right mental model. The back cover blurb on Flashman and the Angel of the Lord sums it up well: "Everyone knows the story of John Brown's raid on Harper's Ferry, planned as the first blow in the war on slavery just before the Civil War. But what most people don't know is that behind this historical milestone cringed an English soldier-adventurer whose only interest was in bedding every woman in reach, evading danger in every form, and immorally profiting from every unsavory opportunity. As a result of the weaseling scoundrel's letching, lying, cheating, and stealing on land, on sea, and on the rails, not only did John Brown become a martyr, Lincoln become President, and the nation plunge into a bloodbath, but the most lustful dreams of a startling number of lovely ladies on both sides of the color bar turned torridly true."

The historical detail is absolutely flawless, and the storytelling topnotch. Here's an excerpt, the opening of my very favorite, Flashman and the Redskins:

I never did learn to speak Apache properly. Mind you, it ain't easy, mainly because the red brutes seldom stand still long enough -- and if you've any sense, you don't either, or you're liable to find yourself studying their system of vowel pronunciation (which is unique, by the way) while hanging head-down over a slow fire or riding for dear life across the Jornada del Muerto with them howling at your heels and trying to stick lances in your liver. Both of which predicaments I've experienced in my time, and you may keep 'em.

Still, it's odd that I never got my tongue around it, for apart from fleeing and fornication, slinging the bat [British army slang: speaking the local language] well is my strongest suit; I speak nine languages better than the natives and can rub along in another dozen or so. And I knew the 'Paches well enough, God help me; I was even married to one for a spell, banns, beads, buffalo-dance and all, and a spanking little wild beast she was, too, with her peach-brown satin skin and hot black eyes, and those white doeskin leggings up to her thighs with the tiny silver bells all down the sides ... I can close my eyes and hear them tinkling yet, sixty years after, and feel the pine needles under my knees, and smell the wood smoke mingling with the musky perfume of her hair, and the scent of the wild flowers outside her bower ... the soft lips teasing my ear, murmuring "Make my bells ring again, pinda-lickoyee [literally, "white-eye", a white man] ..." Aye, me, it's a long time ago. But that's the way to learn a language, in between the sighs and squeals, and if it didn't happen in this case, the reason is that my buxom savage was not only a great chief's daughter but Mexican hidalga on her mother's side, and inclined to put on airs something peculiar, such as speaking only Spanish in preference to the tribal dialect of the common herd. They can be just as pert and hoity-toity in a Mimbreno wickiup as they can in a Belgravia drawing room. Fortunately, there's a cure.

But that's beside the point for a moment. Even if my Apache never progressed far beyond "Nuetsche-shee, eetzan", which may be loosely translated as "Come here, girl," and is all you need to know (apart from a few fawning protestations of friendship and whines for mercy, and much good they'll do you), I still recognise the diabolical lingo when I hear it. That guttural, hissing mumble, with all its "tz" and "zl" and "rr" noises, like a drunk Scotch-Jew having trouble with his false teeth, is something you don't forget in a hurry. So when I heard it in the Travellers' [an upper-class London club] a few weeks ago, and had mastered an impulse to dive for the door bawling "'Pash! Ride for it, you fellows, and save your hair!", I took stock, and saw that it was coming in a great spate from a pasty-looking specimen with a lordly academic voice and some three-ha'penny order on his shirt front, who was enthralling a group of toadies in a corner of the smoking room. I demanded to know what the devil he meant by it, and he turned out to be some distinguished anthropologist or other who had been lecturing to the Royal Geographic on North American Indians.

"And what d'you know about them, apart from that beastly chatter?" says I, pretty warm, for he had given me quite a start, and I could see at a glance that he was one of those snoopopathic meddlers who strut about with a  fly whisk and a notebook, prodding lies out of the natives and over-tipping the dragoman on college funds.

And now you'll have to read it if you want to find out what happens. There are 11 books in the series, and I wish there were more. You probably will, too. Your local library probably has at least a few of these. But two people I've introduced them to, including my father-in-law, jumped onto and ordered the complete set on finishing the first one. Don't be surprised if that happens to you, too.

Disclaimer: This section will often refer to commercial vendors of products or services. Rolling Thunder Computing receives no compensation from these vendors in any way, shape, form, or manner; and would decline any if offered.

 Annabelle And Lucy's Latest

And now, the moment for which I know you've all been waiting -- the pictures of my two girls. Lucy Katrina is now ten months old. She's standing up, and cruising around holding onto things.  She'll be walking any day now.

Annabelle, the first girl, is now three and a half years old. She's very protective of her little sister, telling strangers on the playground to stay away from her, "because she's OUR baby." She likes jigsaw puzzles, and has gotten very good at them. She took a new 100-piece puzzle with a picture of a mother and baby elephant, and zipped through it in an hour (with just a couple of breaks for Halloween candy), without any help from anyone. The thought of her choosing my nursing home is scary as hell.




Subscription Information

Thunderclap is free, and is distributed via e-mail only. We never rent, sell or give away our mailing list, though occasionally we use it for our own promotions. To subscribe, jump to the Rolling Thunder Web site and fill in the subscription form.

Legal Notices

Thunderclap does not accept advertising; nor do we sell, rent, or give away our subscriber list. We will make every effort to keep the names of subscribers private; however, if served with a court order, we will sing like a whole flock of canaries. If this bothers you, don't subscribe.

Source code and binaries supplied via this newsletter are provided "as-is", with no warranty of functionality, reliability or suitability for any purpose.

This newsletter is Copyright © 2003 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.

Thunderclap is a registered trademark ® of Rolling Thunder Computing, Inc., Ipswich MA. All other trademarks are owned by their respective companies.