The Software Monoculture argument is being made again in software development circles. The monoculture idea is borrowed from agricultural science where viruses and insects can devastate a uniform crop planting. This is exactly what wiped out a nascent hydroponics industry in the Maritimes, when only one basic variety of two crops were ravaged by infections. The argument is that with monoculture like Microsofts 90%++ desktop OS, browser and development tool monopolies; Ciscos equivalent hammerlock in network OS, and Java for cross platform development – IT shops and software developers are setting themselves up for attack by hackers and the like – because only one major software pathway has to be breeched, making the job easier.
So goes the argument made by Robert Lemos at CNET, that in effect using Firefox is smart because it reduces dependence on the IE browser monoculture. But Jeff Duntemann at SDTimes takes the argument one step further and argues that the monoculture flaw is even more basic – it is due to the almost total dependence on a common C/C++ language used in most software development today. So Jeff argues that its not the fact that Microsoft wrote “Just Good Enough” code for such a longtime but rather that all developers used (and most still do)C/C++.
And as Jeff argues there are perfectly rational reasons for doing so. ISVs and IT shops reduce costs by buying into a much bigger base of programming expertise – more eyes with more experience and therefore capable of finding bugs and at a cheaper cost than say Delphi or Java programmers. Then Jeff makes a cogent argument why this spreads to IT shops in general:
“In corporate IT, monoculture happens because IT doesn’t want to support diversity in a software ecosystem. Supporting multiple technologies costs way more than supporting only one, so IT prefers to pick a technology and force its use everywhere. Both of these issues are the result of free choices made for valid reasons. Monoculture is the result of genuine needs. Technological diversity may be good, but it costs, in dollars and in effort.”
And it is hard to disagree with Jeff. C/C++ has been security flawed for a very long time. The whole culture of C/C++ has been a petal to the metal culture in which C/C++ was as good as if not better than coding in Assembler for speed and performance. Such security measures such as “try/catch/finally”, exception escalation/resolution, restricted memory management and dynamic range/address checking were late imports to C/C++ from reliability and security conscious languages like Ada and Java.
But it is attitude and good programming practice too. Microsofts IIS was getting clobbered in comparison to Apaches Web server in terms of security and reliability. So Microsoft took an extreme security/reliability approach to IIS version 6 and produced code that has been nearly as good as Apaches code. But the problem is that IIS is a relatively small code base, Windows Server and its libraries are not. And because IIS+Windows falters more often than Linux+Apache, Apache has gained a lead in web server installations of 2 to 1 over IIS which it has not surrendered.
In effect I am arguing that a programming culture that supported “Just Good Enough” software for such a long time, goes a long way towards explaining the constant availability, reliability and security problems with Microsoft software. Also Redmond is going to have a hard time adapting to the rigors of the “-ties”: availability, interoperability, reliability and security. So despite, the proclamations from 4 years ago, that the .NET Framework would bring the “-ties” to Microsoft programming I have to say it again – I am from Missouri. Microsoft has yet to demonstrate they will consistently choose availability, reliability, security over the paparazzi glitz of transparent and 3D GUI or the expedience of bypassing .NET in their own development tools (.NET was not used in any major Microsoft software in a major way until SQL Server 2005…2006 or Visual Studio 2005).
Java and Ada were built on the disciplines of security, reliability, availability yet interoperability. The latter requirement, interoperability, raises the stakes on security, reliability and availability because interoperability means the riskier propositions of shared code, open interfaces, and various coupling versus performance trade-offs. Originally, .NET had this interoperability mandate with many university researchers and languages invited to join the CLR bandwagon and the Open Mono project developing a .NET version for Linux. But the costs of moving to the CLR framework for many languages has meant lost features and functionality fitting into the CLI/CLR/Common Base Library mold. And the Mono project has stopped trying to stay up with the latest changes in .NET and has much more limited goals. And the word interoperability can be barely spoken by top Microsoft managers. And now C++/CLR has achieved ascendancy over C# in the Redmond development world. Is a return to Glitz and Just Good Enough very far behind ? The problem is not monoculture, its moral culture.
(c)JBSurveyer