In the early days of instant-messaging, ICQ dominated. They had a huge user-base for the period, luring even more in with a rapidly evolving application featuring a market-leading array of features and functions (despite the fact that they had one of the most polluted websites on the net. Worse than even Excite after they went all crazy. Trying to find the latest release or how to reset a password, among any other normal use, was an exercise in seemingly intentional obstructionism).

I used ICQ. Everyone I knew used ICQ. IM was pretty much synonymous with ICQ.

While the people behind ICQ were guilty of forever calling it a beta (a product in wide "production" use is not a beta regardless of any exculpatory, defeatist-shrug labels are affixed to it, and that misnomer needs to be eradicated. At least Flickr made light of it by calling their production a Gamma version), it was very usable, relatively lightweight, and earned its position in the marketplace. It also allowed offline messages since early on, which is a feature that some IM networks still don't offer (usually under the premise that offline messages should be facilitated by email, which would be similar to email refusing to send a message if the recipient is available, forcing you to phone when that option is available).

As ICQ took the market by hold, paranoia was rampant that ICQ was just about to start charging for the client, or per message, or that it'd become infested by pop-up ads, and so on. It just didn't seem to make sense that they offered so much with no obvious revenue model.

Then they were bought out by AOL for a staggering $287 million dollars ($410 million if performance hit targets), proving that they had a brilliant revenue model after all.

In the wake of the purchase, some users stuck with ICQ, or they migrated to AOL's client, but I suspect a huge number of former ICQ users took the opportunity to investigate alternatives. Clearly many moved to MSN. AOL of course was already growing their own userbase, obviously catapulting off of their captive audience (similar to what Microsoft did with Windows Messenger)

I now mostly use Miranda IM or Gaim, connecting to several IM networks, and the majority of users who used to appear in the ICQ list now appear in the MSN list, with only a very tiny number of holdouts. I've never heard a later newcomer to the IM field mention ICQ, much less even know what it is or was.

While ICQ still technically exists under the umbrella of AOL, it's a small and relatively inconsequential niche considering its early complete and utter dominance. Perhaps such a fate was inevitable against competitors who could "cross-sell" IM with one of their other products (be it the operating system or the ISP), and the $400+ million dollar bounty was a mighty fan cash-out.

When I was a young buck in jr. high, I was recommended for, and eagerly agreed to, Junior Achievement. It's basically a geek club for prospective future pointy-haired bosses: You do an "IPO", selling shares to friends and family, and then plan and make (or acquire) some craft or spice rack, foisting it on family and relatives. Then you celebrate your profits. Or, if I recall correctly, you distributed the profits to the shareholders (who were generally the same people you sold the product to).

I don't believe any of this was overseen by the OSC (Ontario Securities Commission. Much like the SEC, but most of the power here lies at the provincial level).

Normally you do this program once, leaving room for future leadership-hopefuls to learn from it. There was a long list of kids hoping to get in, so it's not like they needed chair fillers.

Our first order of business was voting our "leadership committee". I decided that I'd go for one of the positions -- we're there to learn management and business administration, I thought, so it seemed the right thing to do -- so I went for procurement manager or something similar. Remember that you operate under the guidance and direction of local business leaders.

That's when us green recruits discovered that a group of individuals had returned to the program up to 4 times in a row, and were very chummy with the bona fide adults who led our group. For every position there was someone who'd done the same position multiple times, going up against the green recruits.

Despite the fact that I got significant popular support (my petition to the crowd was that I should be voted in because I was new to it, a message that really appealed to the audience. It's hard to be a tyrant in a real democracy, and this group seemed to be clamoring for noob representation), after taking the write-in votes outside and tabulating them, the two adults leading the program returned, ballots having been discarded, to proclaim that the existing incumbents were once again reelected.

What was left for the rest of us? Well, we got to do the manual labour, and we got to try to sell this stuff to people we knew.

We got to bask in the glory of our leadership team.

Nah.

I never went back. If they were using my ball, I would have taken it and gone home.

I've always pondered whether I was a sore loser, or whether this particular program was misrepresented. I lean towards the latter.

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.