Long ago, I was pointed to a most insightful post about coding culture at Microsoft (Bill's company) compared with Apple (Steve's company). They observed that at Microsoft, there is a tendency is to use trees as the preferred data structure. Trees are certainly convenient and appropriate for many underlying representations, and are generally easy to manipulate. At Apple, on the other hand, there is a tendency to use hash tables.
Trees tend to impose a hierarchy, enforcing a one-to-many structure (regardless of natural relationships). Hash tables are a looser form of association, which don't necessarily impose structure. This distinction tends to reflect a subtle but significant difference in the underlying philosophy and approach to problem solving and architecture.
And what I've noticed, at several levels, is there is another fundamental difference in thought patterns between the two companies, especially when it comes to coupling. Coupling is (in Software Engineering terms, not the brilliant BBC comedy) the level of knowledge one component has of another, a measure of dependence. Highly coupled code is fragile and difficult to maintain, in that changes in one module may necessitate changes in the dependent module. Loosely coupled code is supposed to rely only on public interfaces, is abstracted from the implementation by its interface, and is more maintainable and resilient to change.
Bill's House
Microsoft often tends to go for tight coupling. This is evident from the code at the low levels, to their architecture at the high levels, to the protocols that connect components. Certainly, at the product level there is no doubting that Microsoft go out of their way to integrate (a synonym for a certain type of coupling) their products, horizontally and vertically. For example: Outlook is tightly coupled to Exchange. Thre are many features that are only available to users of either product when used together. This necessarily implies that they have a significant degree of knowledge about each other.
This was illustrated in a striking way in a posting by a senior Microsoft employee involved with Windows development, who very candidly highlights some of the many problems plaguing Vista and delaying its release:
Windows code is too complicated. It's not the components themselves, it's their interdependencies. An architectural diagram of Windows would suggest there are more than 50 dependency layers (never mind that there also exist circular dependencies). After working in Windows for five years, you understand only, say, two of them. Add to this the fact that building Windows on a dual-proc dev box takes nearly 24 hours, and you'll be slow enough to drive Miss Daisy.
If you look at the Windows API level, down at the code: there are countless examples of where one object relies on the particularities of another. (Note: This is based on my past prorgamming experience with the Win32 C API and MFC, the thin wrapper around it. I have no experience with .NET, so cannot comment on that. I do note however that many experts have complained about architectural shortcomings of .NET v1.)
Microsoft's tendency for coupling is also often used strategically, as leverage to keep control of the platform, or to keep competitors out of a market. There are several high-profile examples of this, such as the recent EU antitrust case.
Steve's House
Apple on the other hand tends to go for loose coupling. They frequently embrace open protocols and standards, which inherently promotes loose coupling. The Mac OS X architecture features many examples of loose coupling. Apple tends to make up for the lack of integration of disparate packages by providing "glue", typically user-friendly front-ends to frequently complex back-end systems. They're not perfect, they do have plenty of proprietary software products, but they use open systems where it makes sense.
At the API level, even at the object level, interfaces and protocols (the Objective-C kind) keep the lowest levels decoupled. I have not seen a more flexible GUI framework than Cocoa (and I have used many), and it is largely due to its elegant design and decoupled nature. It is incredibly easy to customize the behaviour of the interface widgets, because the interface is decoupled from the implementation.
People often complain that Apple use underhanded strategies to keep control of the iTunes/iPod market. But take a look: the audio codec used is AAC (Advanced Audio Codec, an ISO standard), the file format is MPEG-4 (another ISO standard, not coincidentally based on Apple's own QuickTime). The video format used is H.264 (MPEG-4 Part 10, a standard). The DRM is only there at the insistence of the paranoiacs in the Recording Industry, and as Steve points out, he'd rather do away with it (and in fact has for many labels now, such as EMI). Now there is certainly tight coupling between the iPod, iTunes and the iTunes Store, as the entire experience is designed to be streamlined. But you don't have to use the store to use an iPod, and vice versa - it's simply easier that way.
An obvious criticism to this argument is that Mac apps are coupled to the Mac platform (operating system and hardware). While patently obvious and correct, Windows apps are similarly coupled to the operating system - you just get to choose which hardware you run it on. The cost of that flexibility is paid in driver compatibility issues, integration problems, flaky system support, and so on. It's a trade-off that many are happy to make. In any case, I'm more interested in coupling at the application and protocol level.
Steve seems to be quite content to cater to the upper end of the market, rather than taking over every space in every market. Being smaller, Apple simply doesn't have the weight to throw around and force people to use their products, so in some ways they have to be more flexible (viz the Exchange support in Mail.app, or Active Directory support in Leopard Server for example). So to survive, Steve has to ensure (at least to some extent) that the products are not too tightly coupled together.
My Dream Home
I'd like to build a software house, one that embraces standards, empowers customers, and uses creativity and clever design to gain market share, not patents. And of course, I'll always try to keep my code nicely decoupled - and use hash tables and trees where appropriate!
