I spent much of Wednesday in Pearson Airport's decrepit (but soon to be demolished in the staggeringly expensive upgrade of the entire airport) Terminal 2, wondering what the deal was with our flight that was supposed to be boarding.

The help desk sat vacant -- as it had for hours -- and the nearest information board was literally about 1300 feet down a walkway towards the terminal hub. I'd made this walk several times (for epic adventures such as the "going to buy a bottle of water, because the change machine down here is broken and I didn't dare try bringing change through airport security because I have enough junk to worry about already" journey) and it was really starting to get old.

There was approximately one (1) dual-outlet power gangplate in the entire facility -- which I managed to win from a gaggle of nervous-eyed crackberry users, all of us desperately fighting for the ability to siphon some precious electrons (I like to call it "invisible oil") into our drained batteries.

Yet despite this seeming hostility towards the accoutrements of modern life, the facility is surprizingly equipped with ubiquitous, free wireless.

The wireless allowed me to make a secure VPN connection elsewhere (I wouldn't trust anything over an unencrypted channel on public wireless), actually making use of the time to get some work done. It really is empowering checking code out of and into Team Foundation Services, doing database changes, and then rolling out deployments, all from some random chair in some random airport.

It also allowed me to visit Air Canada's website to check on the status of the flight.

Whoops, maybe not. Looks like there was some sort of java error on their middleware (which I know because they strangely feed the entire error stack to end users, rather than having a more professionally refined default error page). This stayed this way for as long as I bothered to continue checking, and made the website completely useless for this task when I actually needed it.

Coming back on Thursday, a late night had me crunched for time, so I wanted to check the schedule for New Jersey Transit's train to Newark Airport from New York's Penn Station. Just needed to know when I needed to catch one -- I'd never been on it before, and had no idea what the frequency was -- and how long it'd take.

No dice.

The online train schedule information system was down. Just had to hoof it and hope. Luckily there was one in the station, ready to go. Maybe there's always one queued, but I wouldn't know it from their information system.

Today I wanted to order a gift from the Future Shop's website. After a detailed error message, it then flipped to a message proclaiming that they were doing "routine maintenance".

Then there are the amateurish downtimes that have occurred on some of the large meme sites, when moves or upgrades that should be seamless end up causing hours of outages. I'm a huge fan of Flickr, but even their recent moves were far more disruptive than they should have been (though they certainly have much more of a justification -- namely petabytes of pictures on a top tier website -- than some jokers running a "lists of links" type website).

These are hardly isolated incidents, and I'm not trying to pick on particular organizations. It just happens to be the most recent frustrating demonstration that the web isn't where it should be, and far too many teams consider reliability to be much less of a concern than it rightly should be.

I've been doing software for long enough to know that few systems are foolproof, and that sometimes eventualities conspire against the best laid plans of the most considerate, skillful world class teams, but these sorts of should-be-exception situations are happening with increasing frequency.

Despite all of the improvements in computer science, and the advances in the platforms that we're developing against, the net direction seems to be downwards, with reliability apparently coming after all else.

This isn't a good trend.

QuickNotes

Office 2007 is quite nice, though from my experience it's a little bit unstable. Between Word crashing while attempting to use the blog editing functionality, and Excel crashing at the oddest of times (the same experience being had on two completely different make and model of machines, with very different software stacks and few commonalities), it seems to be a fairly regular occurence. Finally the blog functionality in Word just stopped working altogether. On the bright side the document recovery is extremely capable, and I've never lost even a keystroke of typing, as it seems to be keeping a realtime backup going.

While I signed up for the original Monad public beta, I never really gave it more than a cursory look: It seemed really incomplete and unpolished. It also irked me somewhat that Microsoft couldn't just embrace one of the existing scripting languages -- say python or perl -- even if they were invented elsewhere, but had to go and invent something new (although I've grudgingly come to appreciate their reasoning).

In mid-October it came out in release form, having been renamed PowerShell.

I've finally got a chance to try to incorporate it, and thus far it looks very nice. While this isn't something that you're going to build a product upon, good automation scripts are instrumental in good development practices, eliminating inefficiency, and the morale-suckage that goes along with repetitive, manual tasks, but more importantly eliminating the inevitable error when people are given such tasks.

It's well worth a close look for automation scripts on the Windows platform. Certainly beats .bat.

Reading through the documentation, however, the following gave me a good chuckle.

One major advantage of using objects is that it makes it much easier to pipeline command, that is, to pass the output of one command to another command as input...

...Windows PowerShell provides a new interactive model that is based on objects, rather than text...

...In the following example, the result of an IpConfig command is passed to a Findstr command. The pipeline operator (|) sends the result of the command on its left to the command on its right. In Microsoft® Windows® PowerShell, you don't need to manipulate strings or calculate data offsets...

PS> ipconfig | findstr "Address"

Ah...good stuff.

Of course in that case the vaunted example isn't using objects (well I suppose the result is a set of string objects, but the example makes no use of them, and completely fails to convince as to the difference), it's just using the stdout of ipconfig, and that command of course works in a classic cmd.exe (or even command.com) session.

Of course some people are surprized that Windows has any command line functionality. In the examples for PureJPEG

..to anthropomorphize toys.

The scene of the room full of viciously abused toys, all quietly sobbing while reminiscing the days when their owners cared about them and treated them well, is far too common in Christmas movies.

Do kids need this guilt? Do they really need to ascribe higher meaning to what are, in actuality, pieces of fabric, apple cores and recycled Chinese newspapers?

It's just a throwaway toy! Use it and abuse it, and toss it in the garbage with extreme prejudice!

Geez.

I convince my children to care for their toys by factually, and truthfully, informing them that a broken toy = a garbaged toy = one less toy to play with (not that such exhortations achieve much with a preschooler and a toddler, but at least they're a captive audience). I don't try to sucker them into thinking the toy feels pain, or cries at their misuse.

Joel recently posted a critique of Vista's shutdown menu, declaring that more choices are a bad thing. This was a surprizing observation given that the new Vista design brings the two overwhelmingly popular shutdown items -- sleep and machine lock -- to featured interface buttons, while hiding less used functionality in a pop-out menu.

Ignoring the seeming contradiction of Joel's analysis, shortly thereafter a former MSer posted about implementing that specific feature, detailing all of the bureaucratic bunglings that led to the eventual implementation. A widely quoted point was that at times up to two dozen people worked on this particular feature.

Is that really all that surprizing? We are, of course, talking about a critical UI element of the flagship of a $300 billion dollar company. In particular about one of the most communicated and referenced features of an operating system that will see installation on hundreds of millions (possibly over a billion) PCs.

Is it really that extraordinary that a large number of people were involved? I'd be surprized if it were any other way.

Joel embraced this response, holding it as evidence that the company has lost its way, becoming the bloated monstrosity that takes 5 years to create Vista. He certainly isn't the first to fondly recall the days when Microsoft was great -- Mini-Microsoft, an anonymous personality calling for the return to the days of old for some time (most notably calling for a significant head count reduction to reduce the bloat) has been leading the charge, along with a loud chorus of supporters.

Are we talking about the same Microsoft? The Microsoft that brought out the travesty that was Windows Me? The Microsoft that had an absolutely atrocious legacy of slow to market, insecure, bug-ridden, ripped off products? The Microsoft that went close to a decade with negligible changes in the Office suite?

I marvel that people can seriously reminisce about the good ol' days of Microsoft with a straight face.

While there is no doubt that Vista was a product timeline disaster -- though I would imagine it has far more to do with technological overreach and unfounded optimism than bureaucracy overload -- Microsoft has been releasing some very solid, feature-rich, secure applications with pretty good regularity.

IIS 6. .NET 2.0. Windows 2003 R2. Visual Studio 2005. Analysis Services. Reporting Server.

These are extraordinary products, overwhelmingly eclipsing their offerings from the late 90s in every way.

If I had a choice between the Microsoft of yesteryear and the Microsoft of today, I think the choice is pretty clear.

Every gym I've ever gone to has featured a never-ending battle between those who shirk their post-set machine cleaning duties, and those who detest the sweaty stink left after the prior user slinks away without dutifully using the sterilizing spray and paper towels to appropriately sanitize the area.

Short of video evidence and instant membership bans, this battle will never be won. There will always be people taking a quick look around and then shuffling over to defile another machine.

Given that it's as probable as not that any random machine has the leftover pore secretions of the prior user, and it's unlikely to change, why not just accept defeat? Decree it the standard that all users should clean the machine before they use it. Levy no post-use demands.

Not only does this allow for the reality that many people have little concern for the next guy, the cleaning job will likely be vastly superior if people are cleaning for their own use. Those who really don't care can enjoy their collection of skin growths, and those who are really paranoid can appropriately equip themselves with high-proof anti-microbial, and some good defensive clothing/towels.

There once was a time when the usable maturity of a platform could be measured by the gross cubic-feet dedicated to it at the local book store: More shelf space generally correlated with a more usably mature platform. A platform where development was often much easier.

Rather development was much more empowered, as it generally indicated that there were enough supports that you weren't sidetracked fighting the basics or reinventing the wheel, but instead were standing on the shoulders of greatness, pushing new boundaries of computer science.

Or at least implementing basic business requirements with a good probability that your needs can be fully accommodated in a relatively painless manner.

Applying the bookshelf metric, one would have observed that cobol probably wasn't a great development platform for most projects (outside of archaic insurance systems), despite its chronological maturity, whereas there was tremendous support for the C++/Windows platform.

As time went on, Java took the bookshelf lead, then saw its share pecked away at by the various web development platforms and the onslaught of Linux/UNIX.

The bookshelf metric really doesn't hold significance any more. Nowadays the dead-tree programming language industry caters more to the technological tourist than the serious developer (or the programmer desperately trying to earn team cred by stocking their bookshelves with various never-opened tomes). The last time I seriously used a programming-language specific book as a development aid was the 30lbs of Windows API manuals delivered with Visual C++ 1.0 back in 1992 (which I got as a present from my wife, though she wasn't my wife at the time. At the time I had been leaning towards focusing on the UNIX world, and my primary development environment was DJGCC, so it was an interesting change of focus).

Today's parallel of the bookshelf metric is the search-efficiency metric. Instead of simply measuring the number of pages referencing a given platform (such that the TPCI index does. I'm very cynical of measuring gross references simply because some languages have a lot of noise and bluster but extraordinarily little real world use. Hype languages generally feature a million beginner and advocacy pages, but close to no advanced or even intermediate pages), the search-efficiency metric is something you inevitably observe as you confront normal questions and impediments with a platform: How easily can you find answers to questions you face getting started, and then doing real-world development?

I've been a believer in the search-efficiency metric for some time.

Back when .NET was going through alpha and beta cycles, a peer advocated that we immediately drop all of our current development (on a mature, well-supported platform) and transition over. I was completely against the idea. Not because I didn't believe in .NET, but rather because some cursory analysis led me to believe that we'd be pioneers in many realms, basically clearing the path for future developers. That wasn't something we could afford with a tight deadline and demanding customers.

When .NET matured a bit, and a good archive of information detailing people's common problems and concerns, and their implementations of common needs, we could catapult forward.

Some time back I posted the following on a discussion board I frequented at the time, wishing for the described feature to bless the SQL Server database engine:

Automatic relational lookup fields. e.g. Someone has a table where they store, for instance, a form name. They store this nvarchar(64) (say averaging 30 characters, averaging 60 bytes a record) over and over again, redundantly. In a table with millions of records there are only a dozen variations of the form name, and the end result is tremendous bloat of the data, indexes, and of course lookups are that much slower as well because of the I/O requirements. To some database designers this is a reasonable design because it is using a natural key (rather than an artificially generated autonumber), but it is extremely inefficient with space.

I would love the ability to toggle a boolean switch on the column and SQL Server will automatically setup a hidden lookup table; which it will automatically maintain based upon values inserted. Concievably it could also scale the relational value (e.g. tinyint, smallint, int, bigint) based upon the number of values in the lookup. Of course I normally do this myself, but when you walk into a large system that exhibits this sort of issue pervasively, it's difficult to fix - you can hide the table behind a view, and use some INSTEAD OF triggers to do the auto-mungification, however that is a leaky abstraction, as Joel would say (e.g. INSERT FROM fails, Enterprise Manager doesn't use it properly, and so on). It's such a brainless, rudimentary task, it is one of those simple but effective features that would be worthwhile and would improve SQL Server.

Back to your regularly scheduled program.

Most of the replies completely missed the point, going off on tangents about how the database should be normalized better (not always an option when you have largescale, widely deployed enterprise systems. Not to mention that using large natural keys can be completely normalized, but still benefitting from this sort of improvement). Others suggested that the database engine should be as dumb as possible, doing nothing beyond storing tuples in the simplest and most obvious manner.

This came back to mind seeing a whitepaper about IBM's just released DB2v9 ("Viper"), offering optional lempel-ziv row-level compression, yielding many of the benefits that I mentioned above. This sort of compression, similar to the "compression" described above, would do wonders for a Sugar CRM database, for instance. Of course other implementations have something similar, for instance MySQL's enum field type.