Reenigne blog

The enemy of software is complexity. The more complex a program, the slower it will run, the more likely it is to crash or have security holes, the longer it takes to write and test and the harder it is to modify.

I think that most software is much more complex than it really needs to be. I think that there are a few basic causes for most of the complexity we see in modern software. In no particular order:

• Premature optimization. Programmers making changes to eliminate a perceived inefficiently without checking that there is a real inefficiency, that the change fixes that inefficiency and doesn't cause a slowdown in the system as a whole.
• Legacy optimization. Optimizations which used to be important, but are not necessary with modern hardware design. This can be a tricky one because it's often difficult to justify removing old, fast, working code and replace it with something simpler but slower. I think MAME has struck a nice balance here.
• Political considerations. Management decreeing "this project must be written in Java as it is the latest and greatest thing" when that might not be the best tool for the job.
• DRM. Adding snake-oil to software to temporarily appease copyright holders. To be maximumally difficult to break, DRM must be extremely invasive so tends to cause complexity throughout entire systems. Windows Vista is probably the best example of DRM run horribly amok.
• Hoarding. A company invents some spiffy new way of doing something and doesn't want that method to be available to their competitors, so they patent it or copyright it to force their competitors to solve the problem in a different way. The result is that there are multiple ways of doing any given task, rather than one canonical one. This has a much greater second-order effect as a lot of software needs to be compatible with many other pieces of software, so has to know about n different ways of doing things.
• Refactoring debt. As code is added, removed and changed, the surrounding code should be modified so that the result is as simple as possible, or the resulting software will be an overly complex conglomeration of disjoint pieces and unnecessary duplication. Unfortunately this important step is often left undone (either because there isn't time, or management doesn't realize what an important investment it is, or because there isn't sufficient test coverage to be sure that the refactorings don't cause additional problems.
• Excessively clever techniques. Sometimes somebody will happen on a technique which seems to be particularly powerful, but actually ends up causing more problems than it solves. For example, the preprocessor in C allows you to do all sorts of things which the language does not directly support (like generic programming and domain specific languages) but only in a way which does not integrate well with tools like source analyzers and debuggers, unless these are made much more complex.

I sometimes wonder if there is a great opportunity for someone who would dare to blow up the universe and build a whole new computing infrastructure with a serious case of Not Invented Here (though reusing the best bits of today's software), creating something much simpler and more reliable.

I think Microsoft really missed an opportunity with the Zune. Creating an MP3 player with built-in ad-hoc wireless networking would have been a work of genius had it not been utterly crippled to satisfy content providers. If you "squirt" a song to someone else they can only play it three times and it goes away in three days. Suppose that they had ignored the wishes of the RIAA and instead created an MP3 player which squirted unencrypted songs at random to other MP3 players in the vicinity. It could even compare playlists with other devices in range and squirt songs it thinks the owners of other players are likely to enjoy (a la last.fm). This would be an absolutely killer application for an MP3 player - I'm sure lots of people would buy it just for the unlimited free music and it would make a fortune. Unlike using internet-wide sharing apps, it would be very hard for the RIAA to track down who is doing the sharing, since the networks would be geographically localized.

What about that pesky copyright problem, though? Well, with all the money they made from the hardware, I'm sure Microsoft could afford to fight (and win) a few copyright lawsuits. Saying "you may only use this player with music whose copyright is owned by someone who doesn't mind it being distributed in this way" ought to be enough to comply with the law (assuming no new anti-P2P laws are created in the meantime).

What about having the artists get paid? Well, the player could include software which says things like "Hey, I noticed you've been playing a lot of music by artist X lately, why not buy their new CD, buy tickets to their concert in your area or just donate some money to them so that they can continue to record" and provides convenient links to do any of those things. If those links worked for non-RIAA music as well as RIAA music, it would eliminate the need for the major recording labels altogether. The RIAA definitely wouldn't like that, so it would take someone as big as Microsoft to pull it off.

The software industry is quite unlike any other because (in principle at least) no problem needs to be solved more than once. Each piece of software can build on all the previous pieces.

This puts many companies (especially ones like Microsoft, who make platforms - software which is designed to be built upon) in the curious position of having their partners also be their competitors in many situations. On the one hand, we want to make things as easy as possible for our partners, releasing rich software frameworks to help them improve their time to market. On the other hand, we want to make things as difficult as possible for our competitors by keeping our product code secret.

How do you define the line between product and framework? The extremes are easy - low level functions which are applicable for just about any product (like those for copying a string or creating a window) are clearly frameworks. High level functions like the code in Visual Studio for performing common refactorings or manipulating the solution explorer window are clearly product code because they are really only applicable to Visual Studio (or equivalent products).

But there's a whole spectrum of functionality in the middle which makes it very difficult to draw a hard boundary. Take the command bar code for example. This is the code for manipulating menus, toolbars and commands and allowing users to customize the product by moving menu items and toolbar buttons around and adding new ones. It was invented (and is maintained) by the Office team but is also used by Visual Studio since we have many of the same problems to solve. Currently, command bar functionality is not made available to developers outside of Microsoft. If you want to have customizable toolbars and menus in your own product, you have to add it yourself. But this would be useful for all sorts of other applications, so perhaps we should make it a framework and let other companies use it. The Office team might disagree, since it could make it easier for their competitors to catch up with them.

I think that as a company, Microsoft is (very slowly and gradually) moving from being a "products" company to a "frameworks" company - we're gradually releasing more and more things in such a way that others can build upon them, as it becomes less of a strategic advantage to keep them to ourselves. If we released the command APIs now it probably wouldn't make much of a difference Office's competitors because:

1. They all have their own, incompatible ways of providing equivalent functionality - it would be a very big job for them to switch to using command bars.
2. Command bars only work on Windows and Office's competitors are all cross-platform.

I think we will continue to introduce new innovations in "product only" form (like the "ribbon" stuff in the latest version of Office) and then turn them into frameworks some years later, once it becomes strategically more favorable for us to do so.

I like this trend because it promotes the idea of "software as a science" (in the sense of creating things that others can build upon) and ultimately helps to advance the "automate everything" cause.

If it were technically possible and safe, would you enhance your brain with electronic implants?

Some possibilities:

• A clock, so you would always know what time it is without having to carry a watch, and never oversleep again
• A calendar, so you always know what you have planned for any particular day and time
• A calculator, so you could instantly do mental arithmetic on numbers many digits long
• A computer, so you could perform complex calculations just by thinking about it, and amuse yourself when bored by playing games in your head
• An internet connection, so you can instantly look up anything, send a message or check your email
• A borg-style "hive mind" implant so you can participate in shared consciousness with anyone else who has a compatible implant

Ever try to delete your recycle bin (if you use Windows) or Wastebasket (if you use a Mac)? In some sense it seems like it ought to work (since these are just objects in the system) but in some other sense it seems like it would cause a paradox and destroy the univese (or at least prevent you from being able to delete other things, or crash the machine). Computing brings us many other paradoxes like "compiling the first compiler" and "paging out to disk the code that pages code back in to RAM".