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.