Gauging the Maturity of a Platform

There once was a time when the usable maturity of aplatform could be measured by the gross cubic-feet dedicatedto it at the local book store: More shelf space generallycorrelated with a more usably mature platform. A platform wheredevelopment was often much easier.

Rather development was much more empowered, as itgenerally indicated that there were enough supports that youweren’t sidetracked fighting the basics or reinventing the wheel,but instead were standing on the shoulders of greatness, pushingnew boundaries of computer science.

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

Applying the bookshelf metric, one would have observed thatcobol probably wasn’t a great development platform for mostprojects (outside of archaic insurance systems), despite itschronological maturity, whereas there was tremendous support forthe C++/Windows platform.

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

The bookshelf metric really doesn’t hold significance any more.Nowadays the dead-tree programming language industry caters more tothe technological tourist than the serious developer (or theprogrammer desperately trying to earn team cred by stocking theirbookshelves with various never-opened tomes). The last time Iseriously used a programming-language specific book as adevelopment aid was the 30lbs of Windows API manuals delivered withVisual 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 beenleaning towards focusing on the UNIX world, and my primarydevelopment environment was DJGCC, so it was an interesting changeof focus).

Today’s parallel of the bookshelf metric is thesearch-efficiency metric. Instead of simply measuring the number ofpages referencing a given platform (such that the TPCI index does. I’m verycynical of measuring gross references simply because some languageshave a lot of noise and bluster but extraordinarily little realworld use. Hype languages generally feature a million beginner andadvocacy pages, but close to no advanced or even intermediatepages), the search-efficiency metric is something you inevitablyobserve as you confront normal questions and impediments witha platform: How easily can you find answers to questions youface getting started, and then doing real-world development?

I’ve been a believer in the search-efficiency metric for sometime.

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

When .NET matured a bit, and a good archive of informationdetailing people’s common problems and concerns, and theirimplementations of common needs, we could catapult forward.