Telefilm Canada has launched The Great Canadian Video Game Competition. This competition will see selected small development teams (10 in round one) supported and shepherded through the process of bringing a video game from concept to retail, seeing them mentored by some heavyweights of the Canadian game development market, along with some very substantial "prizes" (e.g. up to $250,000 to create a "playable prototype", and then up to $500,000 in matching funds, apparently matching private investors, to bring it to market).

As a taxpayer, I have mixed feelings about this. Not only is the Canadian game development industry already relatively strong, this seems like a very precarious contest for a government agency to be involved with: Telefilm would be eviscerated by the party of the day if they brought a game like Going Postal or Grand Theft Auto.

It's not my industry, so I haven't read the guidelines, but perhaps they have a "family friendly" disclaimer in the requirements (explicitly or selectively).

Speaking of video games, in the earlier days of software development, every clever developer generally dreamed of riches in the realm of video games. The hacker itch was generally scratched by making a cool new technology demos (I recently reminisced with the Steem Atari ST emulator, and some of the demos -- then running against an 8Mhz processor with limited external supporting chips, unlike PCs today which have tremendous parallel processing with hugely powered I/O, graphics, audio, networking, and support chipsets themselves vastly eclipsing the original power of the ST -- are impressive even today), though few developers had the follow-through to build a complete game. Still, there was a seeming endless onslaught of hundreds or thousands of games every month. People like John Carmack naturally released their hacker urges by buildings games like Commander Keen.

Now the amateur/beginner game market is mostly dead (yeah it still exists, but it is nothing compared to what it was in the 80s or 90s). If you're a clever programmer now, your dreams of riches are that you'll create the next Reddit or Slashdot or Fark, and most of the hacker focus is on "AJAX" or PHP or Python or .NET.

Quite a remarkable shift, and in many ways it's a tragedy.

Most of my less formal socks are in a big upright clothes hamper - 100s and 100s of socks of just a few designs.

I root through it and find a pair when the need arises. It just seems easier than trying to pair them up out of the laundry.

An internal debate that occurs frequently during these sock diving sessions is when I can't quickly find two of a kind, so I consider just wearing two slightly mismatched socks (e.g. where the ribbing on the sock are slightly different sizes).

"But what if I'm invited to an unexpected Japanese tea ceremony?" I think, motivating myself to continue the search.

You think I'm joking, yet this is exactly the internal dialog that I had this morning.

To: My Pet, My Protege; My Pal; My Chum; My Irritant; My Nemesis; My Irrelevant;
CC: My Boss; My Boss' Peer; My Future Boss; My Team; Some Else's Team; Annoyances and Barnacles;

(An author who adds recipients one by one from the contact list generally yields a reversed ordering, with their precious on the right, and their hobbit on the left)

The director of IT just sent out the new Synergizing, Leveraging, And Monetizing strategy paper. As a principal resource in the new initiative, you find yourself a bit unnerved that they included you last in the list of To: recipients.

The outrage!

Their pet employees and sycophants lead the list, followed by the corporate zombies jerkily stumbling towards the inevitable in the next restructuring.

Your email address is bringing up the rear.

The CC: line has the same ordering, though in that case it's the parties not directly involved in the matter discussed.

Reading Patterns

Was it purely an oversight, or was it an intentional declaration about your standing?

"Don't read too much into it!" most people will answer. "Don't be paranoid!"

And those people would often be right: Many times people reuse old To: lists, or they're technical fumblers barely managing to pull addresses from the contact lists, adding them as they come across them in the sorted list and then reevaluating the line to figure out who's missing. They might be intentionally randomizing recipient lists (which is a tactic I generally use to avoid recipient lists conveying more than I explicitly intend). Maybe they intentionally alphabetize.

That isn't always the case, though, and there are often very real, albeit subtle and generally passive-aggressive, communications when people are given the opportunity to "order" or prioritize other people, particularly their coworkers.

Even when it's subconscious, there is still meaning in the order with which participants came to mind. Maybe they're consciously trying to avoid sending a certain message, for instance placing their office romance last on the recipient list.

It's similar to the choice of seating for a wedding -- hardly an accidental venture, no matter how much your blushing-bride cousin tries to convince you that you're in the nose-bleed section by purely random chance.

The Many Avenues of Communication

Today is the beginning of the loose-leaf collections in my neighborhood. It's a time when squadrons of vacuum trucks go grumbling down the streets, tentacle-like leaf sucking attachment probing about, clearing the curbs and roadside of tree litter.

It's a wonderful service by a fabulous city.

To leverage this service, everyone rakes their lawn, pushing piles of leaves up to the curb to get sucked away, carried off to some unseen composting facility.

I went out to rake -- of course at the last possible moment -- to discover that my neighbor, who I share an open grass border with, had just raked. But instead of raking to the clear but unmarked border between the houses, they pulled back and left an extra foot or so, apparently leaving it for me to rake.

Perhaps they're conceding an extra foot of the land to me? In this way I'm a victorious land conqueror!

Perhaps instead they're being jerks, intentionally leaving some extra work for me, maybe as some sort of jab for an unknown slight.

Maybe the lazy son did it and quite simply tried to trim off a little bit of work.

There is information to be read, although it shrouded in a lot of misinformation and misreading, as is often the case.

Eyes Wide Open

I would end with "keep an eye out for these non-direct communications, primarily ensuring that you aren't unintentionally projecting them because people are paying attention", yet most people are already very perceptive to these sorts of subtle hints: Human communication is vastly more involved and complex than simply the words that are spoken or written. Instead this is simply a bit of a thought piece as I ponder the many messages that we convey and receive every day.

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.

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.

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.

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.