The following short quiz consists of four questions and will tell you whether you are qualified to be a "professional." Scroll down for each answer. The questions are NOT that difficult.
1. How do you put a giraffe into a refrigerator?
2. How do you put an elephant into a refrigerator?
3. The Lion King is hosting an animal conference. All the animals attend except one. Which animal does not attend?
4. There is a river you must cross but it is inhabited by crocodiles. How do
you manage it?
According to Anderson Consulting Worldwide, around 90% of the professionals they tested got all questions wrong. But many preschoolers got several correct answers. Anderson Consulting says this conclusively disproves the theory that most professionals have the brains of a four year old. [Hey That's My Bike!] (why are blogspot permalinks always broken?)

Or more to the point, this conclusively proves that Accenture employees think like four year olds, though they bill significantly more for their time.  So hit the local daycare next time you're looking for consultants.  Though I have to say that that's better than I can say for the genius who came up with the name "Accenture", though given what happened to Arthur Andersen LLP, maybe the name change was genius after all.

Earlier today, Sam Gentile pointed to an article by Scott Seely on MSDN.  Later on, Charles Miller at The Desktop Fisbowl posted the following mini-pattern, which I'll post in its entirety for effect:

Name: Error Codes

Context:

You need to provide a stable platform for clients to interpret error occurring in a networked application (for example a web service)

Forces:

• You want to make it as easy as possible for a client writer to inform the user of abnormal conditions. The easier it is to write a client, the more likely your service will be quickly adopted.
• You want to make it possible to write an advanced client that intercepts errors and handles them internally. For example, the client may wish to present messages in another language, or perform some action other than reporting the error to the user.
• Clients should not break if a service's human-readable error codes are changed.

Therefore:

Present error messages both as an easily machine-parsed code, and as a textual description. Client writers may choose to pass the description straight to the user, to interpret the code and take some other action, or some combination of both.

Examples of use:

SMTP, NNTP, FTP, HTTP, etc...

Notably absent from:

Pretty much every web-service designed by amateurs.

Ouch.  I wonder if Mc Donalds is hiring.  Fortunately, I'm about to revamp error reporting in the web service that I'm personally responsible for, so I have a chance to rectify this before Charles finds out and rats me out to my boss.  

Scott has a couple points in his article:

1. Make sure you set the /configuration/system.web/customErrors/@mode attribute in web.config to "On", ASP.NET won't serialize the stack trace.
2. Throw SoapException objects instead of letting your exceptions propagate out to the caller.  This way, you can correctly set the faultcode, and also the detail if you wish. 

According the SOAP 1.1 spec, the appropriate place for Charles' requirement for machine readable codes falls under the SOAP <faultcode> element, and the <faultstring> and <detail> would be the obvious place for the human readable bits.

The default SOAP faultcode values are defined in an extensible manner that allows for new SOAP faultcode values to be defined while maintaining backwards compatibility with existing faultcode values. The mechanism used is very similar to the 1xx, 2xx, 3xx etc basic status classes classes defined in HTTP (see [5] section 10). However, instead of integers, they are defined as XML qualified names (see [8] section 3). The character "." (dot) is used as a separator of faultcode values indicating that what is to the left of the dot is a more generic fault code value than the value to the right.

As an aside, one of the shortcomings of Scott's article is that he suggests using the application trace for your logging.  The problem with the application trace is that it typically is exposed only to requesters coming from localhost, because you don't want to be exposing your debug port to the world.  In the environment I work in, we don't get to do remote logins, so application trace is out, as is logging to the local filesystem, and the event log (we log events of interest to the operations group to the event log, such as when the database is unavailable.)  As the proud (sort of) parent of a production web service, I'm here to tell you that you need to be logging, and you need to be using a real logging package, one that allows you to turn it on and off at runtime, without restarting your application, and allows you to categorize your messages so you can make sense out of the log if you need to turn on "firehose mode" logging.  Log4j in Java or Log4N in .NET is a good place to start. 

The Financial Times ran an article on the hub-and-spoke system currently used by all the major US carriers (excepting Southwest), and a report by the management consultant Booz Allen Hamilton questioning whether the system could survive. 

The problems faced by companies such as American and United were underlined by Booz Allen, which noted that low-cost rivals such as Southwest have typically offered tickets at half the cost of rivals, for routes of about one to two hours, reducing the prices attainable by traditional carriers by 25-35 per cent.  It estimated that there was about twice the required connecting capacity in the US market, provided by hubs, which has led to "sub- scale hubs that compete for traffic, trash prices and create a hyper-competitive environment".

One other problem with the Hub and Spoke system is the problem of single points of failure.  Case in point: ORD in Chicago, which is a hub for the 2 largest US carriers, United and American.  Chicago also has some of the worst weather in the US.  So a bad storm in Chicago can literally shut down the entire US air travel system for a day, not only because so much traffic goes through ORD, but because airlines generally route planes so that they fly through a hub to another city, then turn around and fly somewhere else.  So if a plane doesn't arrive, or arrives late, a second flight is delayed or cancelled as well. 

The article doesn't go into much detail, but another thought occurs to me.  Some cities have made huge investments in new airports; Denver is one of them.  Denver International also has some pretty high landing fees; I'm told that that's why Southwest won't fly into Denver.  Denver's a hub for United, and so it probably gets a disproportionate amount of air traffic because United is connecting so many flights here.  If the hub and spoke model disappears, does this mean that the number of landings at DIA will drop?  And if revenue from landing fees drops, what does this mean to the airport and the city?  There's probably a lot of bondholders out there who'd like to know the answer.

Still, these problems have been apparent for a while, and the major US carriers haven't changed.  I suspect that there's going to be considerable resistance to abandoning hub and spoke; in fact, we've already seen that the major US airlines are far more willing to squeeze the unions (witness the current mess at United), travel agents (in the US, hardly any airlines pay commission anymore), GDS companies (like my employer), and the customer (goodbye, ticket refunds and exchanges) before seriously examining their own business model.

In the midst of goofing around with XSLT, I found that Jeni Tennison has written a book on XSLT entitled XSLT and XPath On The Edge, and it's been available for a year now.  Jeez, how did I miss this?  I'm buying this sight unseen, just because Jeni's one of the few people who's a bona-fide XML guru.  Her XSLT tutorials are indispensable.  I see that she also published Beginning XSLT last May.  I'm not urgently wanting this one, but I'm sure it's great.