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.

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.

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.

Edward Tufte's Beautiful Evidence: Wonderful book. Highly recommended.

A Coding Mercenary

I'm in it for the money.

Don't get me wrong: I love software development. I love finding the smallest, most elegant solution to a problem (I become truly giddy when speaking of the most elegant code structures). I love embracing and exploiting new advances in the industry. I love refactoring code towards perfection.

I love solving people's problems and making systems better and doing neat things and being respected and thought of as intelligent.

Yet in the end, what matters to me most is the compensation: The wage, the bonus, the equity, the benefits. And then some.

There, I've gone and admitted it. Now I'm just a coding mercenary, right?

A Mercenary Against Misleading Rhetoric

Contrast that with the recent claims that there are Nine Things Developers Want More Than Money, or that money is a bad motivator, or that "One thing that programmers don't care about...They don't care about money".

This we-don't-want-no-stinkin'-money thing is becoming a bit of a meme, both by those with the fat wallet who want to keep as much as possible, trying to convince you that you should agree, and developers who want to demonstrate that somehow they must be really good and passionate and great because, they claim, they don't care about the money. Somehow their lack of greed, we are to believe, must make their work more pure. 

I call shenanigans.

Some who claim that they aren't in it for the money are outright lying through their teeth: Instead of rich compensation up front, they're hoping that a short period of poverty will be followed by an embarrassment of riches and influence. You can find this in many startups and open source projects where pseudo-idealistic developers will give the speech about how little money matters, but eventually will detail how their labour of love is going to net them millions months down the road. That's a story that I've heard play out far too many times, and it's just entirely disingenuous and misleading.

It's common for developers (and even just pundits) in the open source market to build as much namespace as they can. Often it pays off, and they get recruited into lucrative senior positions at megacorps, making lucrative dough acting as a bridge to the open source community.

It's like giving a moralizing speech about the irrelevance of money while waiting your turn in the lottery ticket line.

Others are basically young and naive (and usually just out of college), believing that the project they're working on is for the greater good, or that unspoken or vaguely promised compensation will pay off big-time later (again the short-term "money doesn't matter!" creed is a facade of selflessness). They're often the  backend developer working away developing the product, and then getting punted when it hits the big leagues.

"Sorry, gus, but we just sold out to MegaCorp, and they're going to port the data over to their platform and migrate the user list. You're not needed anymore."

Then there are those who truly in it for passion alone. This is a very rare individual, and while many try to present themselves as this sort of person, they are astonishingly rare in real actions and motivations.

Money Is More Than Just Paper

Money is freedom.

A John Carmack interview -- one of the best developers this industry has seen -- from back in 2000 has always stuck with me-

John: I have sufficient money that I don't need to work anymore; I really don't have to. That's a nice freedom, the freedom from anyone having the ability to have any leverage over you, as long as you've got the money to take care of yourself and you aren't wrapped up in having more and more money. There are a lot of people even though they have a lot of money, they can still be manipulated by the carrot of having more money.

His money is the freedom to do what he wants, when he wants to. It is the freedom to say "screw you" to excessive demands (John works overtime because he is so into it, not because someone hangs the axe of job security over his head), and to have the mobility and versatility that such financial means bring.

Many will read this far and see a seeming contradiction in what I just quoted: Isn't John saying that the benefit of having so much money is that he isn't manipulated by the carrot of money, while I'm advocating basically being enticed by said carrot?

Exactly.

The difference is that John is already there, contrasted with the reality that many of us not there are fighting to pay the monthly bills, desperately fearful that we demand too much or present the image of underworking or ask too many questions.

Many developers aren't seeking the carrot of money, but rather they're threatened by the spiked-tipped bludgeon that is the lack of money (aka loss of job). If you think people do the wrong things for extra money, realize that they do far, far worse to avoid the lack of money.

The goal of amassing net wealth is the freedom and confidence that comes with the ability to control your own destiny. It's the ability to live in a nice home, and have children if you want (without desperately clutching onto whatever spin comes out claiming that the lack of choice is a benefit), and actually take a couple of months to go traveling if you wanted. It's the ability to decide to start a business, and to have the leverage and means to do it with minimal stress or risk. This was tip #3 in "5 Tips for Enjoying the Software Development Profession".

And most any activity is much more enjoyable when it's optional. It can be fun "slumming" when you're wealthy, or working in the soup kitchen when you're volunteering, or cleaning garbage on Earth day, while none of those are quite as enjoyable when you have no other choice.

[It should be mentioned that income alone isn't enough, and those who are cursed to spend more than they take in will forever be running to stand still (or go backwards), but I'm speaking to those who have reasonable financial knowledge to efficiently use wealth for quality of life while maximizing their leverage in doing so]

Of Course Money Isn't Everything

This isn't to say that other things don't matter, and I'm not saying that I'd sit on a slimy rock in the pouring rain punching in market numbers for 16 hours a day if it paid well. It also doesn't mean that I'd risk future earning potential working on outdated platforms or working on trainwreck projects or acting as a maintenance programmer when some middle managers sell the executives on the idea of buying an outsourced insurance platform. Yet the importance of compensation can't be underestimated.

It does mean that I'll happily do jobs that aren't sexy or glamorous or superficially interesting (I say superficially because most any programming task of consequence can be challenging and interesting if approached in the right way. Just because it's a P2P app or a first person shooter doesn't mean that it's going to be interesting or rewarding work, just as it isn't intrinsic that Wall Street/Bay Street apps B2B are going to be monotonous, unchallenging, or boring). It doesn't mean that I'll do work that is criminal or morally repulsive.

Watching Out For #1

All I'm presenting here is a bit of a counterpoint, and a bit of advice: Look out for #1, because that's exactly what many of the people you are dealing with are doing (and of course #1 to them is them). Make sure that equity positions are solid, and that the financial rewards align with the risks. Make sure that you're paid enough that you can build enough cushion that you don't become a financial slave, easily controlled and abused.

The CYA Application Security Model is the practice of implementing so-called security obstructions primarily to absolve the vendor from blame if something goes awry during everyday operations. This model is usually sold under the pretense of improving user education, or encouraging safer application usage, but that's of minimal actual concern (in reality the opposite outcome -- more risky application usage -- is probable).

An example of the CYA ASM in action is one that pops up a seemingly endless stream of confirmation "Are you really sure you want to do that?" dialog boxes, warning the user against doing what should be completely normal, benign activities.

This pestering, progress-inhibiting assault of a million warnings and confirmations application behaviour is certain to cause the user to enable a "turn off all security" mode (for instance adding every site to "trusted sites" in Internet Explorer), paradoxically making the security situation infinitely worse, but for the vendor this often the desired outcome: At least then they can smirk and blame it on the userbase if what should be a harmless activity compromises their machine.

Didn't you heed the "The Internet could be harmful to security!" dialog box when you attempted to connect to the internet?

A while back I posted a complaint about the lack of native spellchecking in the major browsers, stating-

In the forum and blogging world, it would be beneficial if more tools supported convenient and efficient automatic spell-checking (the fact that no major browser has incorporated native TEXTAREA spell-checking thus far is a travesty. Any of them could have a killer feature if they simply added Word-like squiggly underlining of suspect words, with easy alternative corrections). As it is, many tools have nothing at all, and the few that do often host a ridiculously unintuitive, hacked-in partial solution.

For those who like release-quality software, salvation is at hand: Grab yourself a copy of the just released Firefox 2; an already brilliant browser that now also supports native data entry spellchecking, with little squiggly (or at least dotted) lines under suspect text, and a suggested list of alternatives.

Finally!

Hopefully this improves the quality of spelling on the net.

And to head off the inevitable comments, no, the lack of spellchecking clearly hasn't somehow improved spelling (usually argued under the "it makes you work harder at it, therefore growing spell-muscles" explanation). Given that our brains learn spelling by example, even those of us who care are misled by a constant stream of misspellings. With the addition of finger-wagging little squiggle-lines, perhaps the purity of the language will improve.

It doesn't analyze grammar, pointing out errant uses of too or to, whether it's a possessive apostrophe rather than a contraction, or help in the endless "that isn't ironic!" debate, but at least it's a start.

The best browser gets even better.