This post by Don Box epitomizes one of the reasons why Microsoft, despite their market dominance, produces some of the worst software in the industry, and has lowered consumer expectations to the point that nobody expects computers to work well or serve their needs well.
Before I talk about Don's post, it is important to note that Don is no entry-level programmer. In fact, Don is one of the architects of the Indigo project, and is responsible for designing parts of the architecture that will make .Net (and your future software applications) work. He has just written a authoritative book, Essential .Net Volume 1: The Common Language Runtime.
I don't mean to single out Don. In fact, I don't even know Don. He's probably a great guy, and his blog is filled with intelligent and insightful posts. But, this particular post reminds me of many experiences I've had while working inside Microsoft on Microsoft teams, talking to the "best" and the brightest. Don's naive understanding of the software world is more typical of Microsoft engineers than most people would believe.
In his post, Don explains how recently, he discovered the joys of Scheme (a dialect of Lisp). Don says:
In writing Scheme programs, I've learned a lot about coding, design, architecture, and aesthetics.
He goes on to enumerate the lessons he's learned: That small is beautiful; that lambda expressions can be a powerful tool; that code can be data and data can be code.
These are things that any 1996 Computer Science curriculum would have contained in abundance. They are an important part of the conceptual framework by which an engineer plots their course, and judges the logical correctness of their solutions. Lisp has been around since 1959, and the very concepts Don is "discovering" were part of the foundation of the language for over 45 years.
The notion that a Microsoft architect could discover such things at this point in his career is almost unthinkable. It's reprehensible. The idea that critical technology platforms are being designed by people who have just discovered such fundamental concepts is terrifying. And yet, time and time again, I have talked to Microsoft high-level engineers who have argued with me about these things, even in one case reinventing the concept of generic invocation and saying it was his own invention. He actually believed it was his own invention, and he was designing part of the COM architecture.
How can such hubris exist among engineers who are not schooled in the basic theories of their trade? Part of it is the Microsoft culture of superiority. In 1994 I worked a team in Redmond who were responsible for integrating my company's technology (TrueGrid) into the VB4 product line. We had thousands of customers, and Microsoft had selected us because our technology was the best-of-breed. The way Microsoft managed this was almost beyond belief.
Rather than trusting the judgement of our team, who had proven in the market that we had a deep understanding of the needs of our users, Microsoft assigned someone who had never written a specification before. In fact, he had never designed a product himself, nor participated in the design and testing of a major product which had been delivered to customers. He was not, in short, a software designer. He was one of the myriads of Microsoft "product managers" whose job entailed evangelism, communication with outside vendors, and was the general "voice of Microsoft" when it came to the ISV partner program.
His specification was awful. He did not understand how to create a scalable interface. Features which were requested were thrown in, often collapsing the utility of other features. We tried to assist by lending our knowledge to the project. We argued. We emailed. We persevered. We lost.
In the end, the technology developed was almost embarassing. What was an excellent product that we had proven satisfied many, many needs well had turned into a poorly designed albatross which even VB users would complain about. It was the low point of my entire career, and one of the chief reasons I divorced myself from the project. In any discussion with Microsoft, there was no reasoning or logic. Because it was Microsoft's spec, it had to be right. It didn't matter that we had superior product and market knowledge.
Microsoft engineers are like alchemists, mixing together technologies and ideas that few of them understand. No wonder the COM object model is such an abortion. No wonder we need 1GB of memory on our computers to run MS Office. No wonder Windows can't reliably suspend on a laptop, or things need to be reinstalled for reasons that nobody understands. Microsoft charges forward, implementing things for commercial selfish benefit, but really has only a rudimentary understanding of how to design software.
In fairness, Microsoft's dominance has resulted in one of the most widespread technology platforms. Windows systems are compatible with one another largely by accident, because they are all running essentially the same software on the same hardware. But, whatever the reason, Microsoft has succeeded in standarizing the desktop, and ultimately that is good.
But, had they done it better, we probably would have had more, sooner. Much more. And it would be more reliable. In fact, if they had done it better, Linux woudn't stand a chance. Think about it: How is it possible that the dominant software monopolist, bloated with incredible cash resources, can be vulnerable to software which has been put together by an unmanaged group of programmers with only a shared vision? How can the open source movement even exist?
Open source is becoming more and more successful for one reason only: Microsoft's persistent production of inferior, poorly designed software.