June 16, 2004

An Insufficiently Debugged Collection of Device Drivers

Joel Spolsky writes about how finally--after a full decade--Microsoft Windows is becoming a large collection of insufficiently debugged device drivers:

Joel on Software: ...I'm not sure how I managed to get this far without mentioning the Web. Every developer has a choice to make when they plan a new software application: they can build it for the web or they can build a "rich client" application that runs on PCs. The basic pros and cons are simple: Web applications are easier to deploy, while rich clients offer faster response time enabling much more interesting user interfaces.

Web Applications are easier to deploy because there's no installation involved. Installing a web application means typing a URL in the address bar. Today I installed Google's new email application by typing Alt+D, gmail, Ctrl+Enter. There are far fewer compatibility problems and problems coexisting with other software. Every user of your product is using the same version so you never have to support a mix of old versions. You can use any programming environment you want because you only have to get it up and running on your own server. Your application is automatically available at virtually every reasonable computer on the planet. Your customers' data, too, is automatically available at virtually every reasonable computer on the planet.

But there's a price to pay in the smoothness of the user interface. Here are a few examples of things you can't really do well in a web application: 1. Create a fast drawing program. 2. Build a real-time spell checker with wavy red underlines. 3. Warn users that they are going to lose their work if they hit the close box of the browser. 4. Update a small part of the display based on a change that the user makes without a full roundtrip to the server. 5. Create a fast keyboard-driven interface that doesn't require the mouse. 6. Let people continue working when they are not connected to the Internet

These are not all big issues. Some of them will be solved very soon by witty Javascript developers. Two new web applications, Gmail and Oddpost, both email apps, do a really decent job of working around or completely solving some of these issues. And users don't seem to care about the little UI glitches and slowness of web interfaces. Almost all the normal people I know are perfectly happy with web-based email, for some reason, no matter how much I try to convince them that the rich client is, uh, richer.

So the Web user interface is about 80% there, and even without new web browsers we can probably get 95% there. This is Good Enough for most people and it's certainly good enough for developers, who have voted to develop almost every significant new application as a web application.

Which means, suddenly, Microsoft's API doesn't matter so much. Web applications don't require Windows.

It's not that Microsoft didn't notice this was happening. Of course they did, and when the implications became clear, they slammed on the brakes. Promising new technologies like HTAs and DHTML were stopped in their tracks. The Internet Explorer team seems to have disappeared; they have been completely missing in action for several years. There's no way Microsoft is going to allow DHTML to get any better than it already is: it's just too dangerous to their core business, the rich client. The big meme at Microsoft these days is: "Microsoft is betting the company on the rich client." You'll see that somewhere in every slide presentation about Longhorn. Joe Beda, from the Avalon team, says that "Avalon, and Longhorn in general, is Microsoft's stake in the ground, saying that we believe power on your desktop, locally sitting there doing cool stuff, is here to stay. We're investing on the desktop, we think it's a good place to be, and we hope we're going to start a wave of excitement..."

The trouble is: it's too late.

I'm actually a little bit sad about this, myself. To me the Web is great but Web-based applications with their sucky, high-latency, inconsistent user interfaces are a huge step backwards in daily usability. I love my rich client applications and would go nuts if I had to use web versions of the applications I use daily: Visual Studio, CityDesk, Outlook, Corel PhotoPaint, QuickBooks. But that's what developers are going to give us. Nobody (by which, again, I mean "fewer than 10,000,000 people") wants to develop for the Windows API any more. Venture Capitalists won't invest in Windows applications because they're so afraid of competition from Microsoft. And most users don't seem to care about crappy Web UIs as much as I do.

And here's the clincher: I noticed (and confirmed this with a recruiter friend) that Windows API programmers here in New York City who know C++ and COM programming earn about $130,000 a year, while typical Web programmers using managed code languages (Java, PHP, Perl, even ASP.NET) earn about $80,000 a year. That's a huge difference, and when I talked to some friends from Microsoft Consulting Services about this they admitted that Microsoft had lost a whole generation of developers. The reason it takes $130,000 to hire someone with COM experience is because nobody bothered learning COM programming in the last eight years or so, so you have to find somebody really senior, usually they're already in management, and convince them to take a job as a grunt programmer, dealing with (God help me) marshalling and monikers and apartment threading and aggregates and tearoffs and a million other things that, basically, only Don Box ever understood, and even Don Box can't bear to look at them any more.

Much as I hate to say it, a huge chunk of developers have long since moved to the web and refuse to move back. Most .NET developers are ASP.NET developers, developing for Microsoft's web server. ASP.NET is brilliant; I've been working with web development for ten years and it's really just a generation ahead of everything out there. But it's a server technology, so clients can use any kind of desktop they want. And it runs pretty well under Linux using Mono.

None of this bodes well for Microsoft and the profits it enjoyed thanks to its API power. The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing.

Posted by DeLong at June 16, 2004 02:58 PM | TrackBack | | Other weblogs commenting on this post

>>Most .NET developers are ASP.NET developers, developing for Microsoft's web server. ASP.NET is brilliant; I've been working with web development for ten years and it's really just a generation ahead of everything out there. But it's a server technology, so clients can use any kind of desktop they want. And it runs pretty well under Linux using Mono.

Obviously he hasn't worked with Struts :P

Posted by: cooper on June 16, 2004 04:03 PM


No he hasn't used Struts (he was turned off of Java earily on and has not looked back). Read his website www.joelonsoftware.com

Posted by: HinderLands on June 16, 2004 04:18 PM


Too bad. Even without Apache/Jakarta, Java has matured to an astoundingly roubust, fast, and usable platform.

It isn't so much that I would tell someone to use Jakarta and not .NET, it is that at least the consumer (developer) will have a credible choice in which platform to use.

Posted by: Alan on June 16, 2004 04:54 PM


That's $50,000 difference also often includes not having to wear a tie.

Posted by: c. on June 16, 2004 06:13 PM


From the oddpost.com, a new web application mentioned favorably by Spolsky:

Account sign up is not available from this machine. Oddpost currently requires Internet Explorer 5.5 (or higher) for Windows.

So is Microsoft really going to lose anything if drop Windows client-side applications for web-based ones?

Posted by: rps on June 16, 2004 07:33 PM


It will turn out to be a very interesting thing if Spolsky is right here about the ascendancy of the web client. For starters, Google really *would* be worth $25 billion out of the shoot. And I think he's right because the web app world is (or could soon be) waaay ahead of where the thinks it is now. So he mentions the potential suckiness of UIs (no non-mouse interefaces) and/or the inability to write a fast drawing program. Gmail already has lots of keyboard shortcuts, and it's still in Beta. Heck, classsic Mozilla (the browser) was mostly built up of just ultra fancy dynamic XML. That was too slow three years ago, but a year from now it won't be at all. Moreover, as more and more complete versions of things like SVG get implemented, the more likely it is that some killer UIs (and even that drawing program) can be done. Things that are slow today are either slow because your computer will be upgraded next year, or are slow because your network connections is still sluggish. Neither of these problems are fundamental except for (maybe) things like networked shoot 'em up video games, which are still network bandwidth dependent in a serious way.

Posted by: Jonathan King on June 16, 2004 09:29 PM


Anyone who stores their mail on Google or Yahoo servers without a way to archive locally deserves whatever they get.

Venture capitalists can dream, but thin clients are not going to take over the world.

Posted by: Petey on June 16, 2004 11:23 PM


The last fat client program that I worked on was in 2000. Everything since then has been CLI and web (CLI because that's what the IT departments need for remote systems they can only get into via modem, web because it's good enough).

Regarding the Java stuff, in 2000 Java was fat, slow, and tedious to write web applications with. All of that is no longer true. Java still has one major drawback: It is only available for a few platforms. For one appliance that I was working with, which was based on FreeBSD, that was a killer problem -- there was no supported Java for FreeBSD, because Sun wouldn't let the FreeBSD folks have the source code under a license they could live with. So that product got done in Python. Similarly, a current product's web GUI is being done in PHP, mostly because there is no officially supported Java for this particular distribution of Linux, and having endured many Java runtime core dumps in the past when running versions of Java that were not compiled against the *exact* same version of glibc, I'm not eager to repeat the experience.

Which just goes to show that commercial support is not the be-all and end-all. Commercial support is why we did NOT use Java in two of my last three products, because commercial support, by necessity, ties things to particular platforms. If the platform I must support isn't one of those platforms, that's when I go to the Open Source solutions -- which run *EVERYWHERE* on *EVERYTHING*. Different version of glibc? Just re-compile! Never again have core dumps because of API incompatibilities... and never again have to let a compiler vendor choose your platform for you. Ah, freedom... "free" means more than just price, y'know?

- Badtux the Programmin' Penguin

Posted by: Badtux on June 16, 2004 11:24 PM


One of the most succinct comments on Windows comes after you have installed your 6.8 gigabyte Windows program. Oh, so you want your mouse to work? "Driver not found. Insert OEM disk now...."

Posted by: serial catowner on June 17, 2004 05:52 AM


"marshalling and monikers and apartment threading and aggregates and tearoffs and a million other things that, basically, only Don Box ever understood"

Please, make it stop, I thought those dark dark years were over. Somehow 130k in NYC doesn't seem like it would go too terribly far, especially if you had to do anything COM related.

Posted by: Gideon S. on June 17, 2004 11:25 AM


I'll say here something I said to my economics professor about five years ago - in the long term, the conventional PC is dead. I figured it would take about thirty years, but I now think it may happen faster now that I've heard some of the details about Google's server farms.

The conventional PC is basically four things wrapped in one - user interface, computing power, data storage, and software programs. Only the user interface has to actually be sitting on your desk. Whether it's economical to put the rest of it on your desk depends primarily on the communications technology between you and remote servers.

Sure, web apps are fairly limited right now, but they mostly have to work with at most broadband connections (where you can't rely on more than 100 kilobytes a second to the client... not even enough to stream video that doesn't look like crap). But when connections commonly reach the megabytes per second range, there will be a realistic possibility of moving the bulk of PC applications onto remote servers.

As has been pointed out here, moving software to remote servers is inherently attractive. It's much easier to deploy, you don't have to worry about piracy, etc. But moving the data storage and computing power away from the UI, so the PC becomes a "dumb terminal", depend on the convergence of several other factors:

1. Communication speed, already mentioned. A lot of the uses of data are inherently local - video to be seen, audio to be heard, documents to be printed and viewed, and so on. If the data is on a remote server you have to get it to the client fast. High quality video for example requires >1 megabyte per second. We are talking transfer speeds at least an order of magnitude faster than current broadbamd. But then you get the possibility of doing a huge number of things remotely over the net, including all audio/video storage and distribution.

2. Cheap cheap cheap remote servers. Today's web servers are mostly much more expensive than PCs. They generally need high reliability and several high-performance subsystems, and so end up costing several times what a PC would cost per unit of storage or processing power. But in theory, there is no reason you couldn't build a distributed network of a bunch of very low end, cheaper-than-the-average-PC computers. And find some way to allocate its resources efficiently - run every processor at nearly 100% load and keep every hard disc nearly full. Since the average home PC isn't used nearly that heavily, you make much more efficient use of hardware. And if you could do it on a huge scale, you could have economies of scale in creating and maintaining these systems that aren't seen by the typical user when they configure and maintain their PCs.

3. "Transitional" applications that make it economical for even people with powerful PCs to use remote applications (rather than the selling point of remote applications being "if you use our service, you can buy a cheap dumb terminal instead of a PC"). For a while it's been fairly obvious that the web would provide a big slew of transitional applications - it expanded the PC market to large groups of people who use their home computers primarily for web surfing (plus home A/V stuff like storing their digital camera photos and MP3 connection).

#1 is coming about as slowly as I expected - broadband gained high penetration in a lot of countries, but so far there is not enough technology and demand to be rolling out multi-megabyte-per-second connections to lots of homes. Indeed in the telecom crash and so forth we generally saw that capacity had been overbuilt. It may take over a decade for a real high-speed infrastructure to be created.

But #2 really surprised me - Google basically has it already. (But you won't see me buying any Google stock because of that - their server farms are more impressive than their search engine, but other companies can and will duplicate their server farms once big enough money shows up, so the likely hypervaluation still won't be justified). Basically they have a network that is a huge number of mega-cheap PCs that they maintain for a very low cost, running a giant distributed operating system that keeps each of them near 100% use. They have it so cheap they can give a gigabyte of email to the general public just to get them to view some ads, so they can keep a stupendously huge web cache just to make their search a bit better and thus get people to view some ads, etc. Things must be really cheap behind the scenes there because even if you're Google, internet ad revenue is still pretty low per impression.

The thing is, this Google-style technology still has to move out into the public for the death of the PC to start moving along. Right now it's one distributed system with proprietary code written for it to the tune of a few high-profile applications. But once you see a system like this open to the public so that people can write their own applications for it (paying for server resources), things will really start to take off. It could dramatically decrease the cost of writing net-based apps because of a dramatic decrease in the cost of maintaining server hardware.

That's why the first thing you should watch out for is Google or someone with similar technology going for web hosting in a big way. Right now web hosting is really inefficient. It costs at least 50 bucks a month for a dedicated server (a fairly midrange PC at that price). If you only want 10% of that PC's resources, you pay a lot more than 10% of that 50 bucks, because web hosts have a high technical support overhead for maintaining their services. It's not all answering support calls either - installing and configuring the software that allows lots of users to run on one PC is a stupendous pain in the ass by all reports.

The killer app of web hosting will be somebody coming up with a distributed shared hosting environment where you can have whatever block of CPU time, disk space, and bandwidth you want, spread among a network of many thousands or tens of thousands of ultra-cheap PCs. An environment that requires very low per-PC maintenance costs (assuming you have thousands), where you can just plug an extra PC into the network and its resources go online with virtually no additional effort other than walking over to plug it in. Someone with this sort of web hosting technology could utterly destroy all the existing competition, making higher profit margins while selling at a fraction of the cost.

Of course there would be a lot of up-front software effort to do this (apart from the huge effort to build a distributed server farm of the kind that, right now, is apparently only possessed by Google). It would be a big development project to build an easy-to-administer shared hosting environment that runs on some custom distributed OS. But not impossible - advanced shared hosting software already exists for single PCs, though it's hard to administer and lacks sufficient configurability (no way for someone to get the ability to run at 100% of CPU for 10 minutes at arbitrary times, without paying for a dedicated server that allocates them 100% all the time).

Watch out for this sort of thing...

Posted by: Ian Montgomerie on June 17, 2004 02:36 PM


>>Regarding the Java stuff, in 2000 Java was fat, slow, and tedious to write web applications with.

You know, I have to say, tedious may be a matter of perspective, but even in 2000 the "Java is slow" thing was generally a myth. By the time 1.2.2 and HotSpot were in wide distribution, Java was more than acceptably fast. Moreover, the nature of J2EE apps makes it so easy to throw hardware at the problem it doesn't matter. In the grand scheme of things, if another $3000 node in the cluster saves you a week of programmer time that would have been spent dealing with running down memory leaks and other such tedium, its worth it.

Honestly, though, if you have no problem with a *lack* of "this is supported version", why not simply use libgjc?

Posted by: cooper on June 17, 2004 02:46 PM


On another note, though, don't underestimate the cheapness of Google's storage. It's obviously very cheap relative to the competition, but in absolute terms they still can't afford to give everyone a gigabyte of email storage now. They know darn well that most people will use maybe 10% of that any time soon, and mostly in text (they would be stupid not to be compressing that text in the background down to a level where the typical GMail user's 100 megs or less of email are 10 megs or less of actual hard disc space, so a typical modern hard disc could serve 10,000 users). EVENTUALLY people will accumulate enough email, especially with attachments, so that many are actually using the bulk of their space. But that will take years by which time hard discs will be much cheaper. Google can reliably bet that from this point onward, hard disc prices will probably drop at least as fast as email volume rises.

Another "killer app" of GMail might be anti-spam. One problem of detecting spam is that even though it is by its nature sent to huge numbers of people, spam-killing software just looks at each message individually (sometimes modified by the spamfighting preferences of the individual recipient). With Google's advanced search combined with the ability to monitor what's going into a stupendous number of inboxes, they could have a fundamental leg up on the spam-fighting competition (though Microsoft/Hotmail/Inktomi would be running to catch up). If you can detect that very similar messages are coming from one point of origin and going to many mailboxes, that's a very good indicator that it's spam.

Of course on the technical end, it is more complicated than that. Spammers fake the message headers so Google couldn't tell the actual sender - but if could likely figure out that a big crop of spam had all been routed through a single point on the net, which is a telltale clue. It could also detect large amounts of spam sent from an identifiable but disposable source such as an anonymous hotmail account. And of course on the content front, spammers have taken to randomizing their messages to better get by antispam software, so you can't just look for identical messages going to many users. You'd have to do a bunch of text analysis... exactly the sort of thing that search engine researchers would be good at figuring out.

Posted by: Ian Montgomerie on June 17, 2004 02:55 PM


This is crap.

Try writing Photoshop in HTML. Try writing Q3A or Hitman or Diablo in HTML. Try writing... oh, do I need to go on?

Do you really want to trust your data to a server somewhere rather than archiving it locally? Do you really want everything you do to be monitored by someone else's network admin, and subject to their veto?

Large companies LOVE the idea of a "thin client" because it gives them control. But where is the advantage to the end user? Really, there's none. Some apps work fine as web based apps due to their nature. But many apps (including, I believe, office suites) really need desktop computing power (thick clients) to be workable.

If Windows is eclipsed, it will be by another desktop OS (probably open-source), not by "thin clients". There is no advantage to the end user for "thin clients" when real PCs are so cheap and available.

Posted by: Firebug on June 17, 2004 02:59 PM


"Try writing photoshop in HTML".

Who said anything about HTML? If you're talking just existing technologies, you could write a Java frontend to a Photoshop-like app on a remote server. Of course it would be rather slow due to sending the results of your edits (at least a viewscreen-sized portion of them) across a standard broadband connection. But at, say, a megabyte a second there would be no reason the average home user couldn't do their image editing remotely.

"Do you really trust your data to a server somewhere rather than archiving it locally"?

Hard drives fail and very few people make backups. Networked storage can easily be made vastly more reliable than anything 99% of home users do with their data. You just have to make sure the company doesn't suddenly disappear. It does happen to smaller operations every so often, though it would be extremely unlikely to happen to the sort of operation running a ten-thousand-server farm.

"But where is the advantage to the end user [of a thin client]? Really, there's none".

1. Portability (this will become far, far more important in the future than it is today). If something is on my PC I can't use it unless I'm at my PC. If I want to get data off my PC, I need to share it across the net and deal personally with the security issues that presents to my PC. If it is on a net-based service it becomes far easier to access anywhere.

2. Cost. As I pointed out there are fundamental technical and practical reasons why it is more efficient to run apps on a distributed network of ultra-cheap PCs, than to constantly maintain and upgrade your very own PC for the purpose. The actual cost of storage and processing time drop, and from the end user perspective turn from entirely fixed costs to entirely variable costs. Competition will eventually bring those savings to the end user. (Think about how much of the average PCs processing power is actually used over its lifetime by the typical user - it's got to be somewhere well under 10% when you consider them sleeping/being at work/etc. and mostly using light apps when they're not).

3. Ease of backups. If you really want loads of backups it is likely that system providers will eventually be there for you, so that even really secure backups (like putting something on long-lasting media and storing it in a vault that you have access to even if the company goes belly-up) becomes affordable, and requires zero effort from you. Whereas right now, for the home user to set up a serious backup strategy is an extreme pain in the ass.

4. Much reduced headaches for Joe User. The more of the system that is remotely configured by the system admins, the less PC-troubleshooting pain and suffering the average person will have to experience.

5. Ability to exceed your normal data storage/processing power needs for short periods without having to pay for sufficient capability to do that 100% of the time. I like to play computer games, for example, but I don't actually do it all that often. So I always face the dilemma - do I spend ~1000 dollars a year on computer hardware to maintain a PC that can give me great performance in games, considering I don't actually play all that many games? It would be a much easier decision if I could just pay for it when I used it.

And that's just what I can think of for now. yes sir, the mainframe will be back, but in hugely distributed form.

Posted by: Ian Montgomerie on June 17, 2004 06:47 PM


I have two problems with the article:

1) This type of article, or one very similar, has been written just about every year for the past 20 years. I'm not saying that the article is wrong but I'm not sure why I should take it any more seriouly than I did those in the previous years.

2) Speaking as a Windows/COM/C++ developer, I have to say that his comments about the desirability of such developers and the salaries they command are grossly exaggerated.

Posted by: PaulB on June 17, 2004 09:43 PM


Regarding Java 1.2.2 in 2000: I wrote web applications using Java 1.2.2 in 2000. On an 800mhz processor. With 192mb of memory. It was painful. Painful painful painful. Java did not become acceptably fast until 1.4 was released. I don't know what platform the person who thought 1.2.2 was plenty fast was using, but it certainly wasn't Linux or Windows.

Regarding gnugjc, what makes Java so powerful is the huge library of classes that Sun has written for it. These typically use proprietary JNI hooks deep into Sun's runtime, and won't run on the open source Java. I looked at the GNU Java and came to the conclusion it wasn't even up to Java 1.1 standards (as pathetic as Java 1.1 was). Java is not a language. Java is a platform. A proprietary platform. That runs only on a few officially supported hosts. And woe to thee if your host is not one of the officially supported ones (if, say, you're using a different Linux kernel or version of glibc than what Java was compiled against by Sun, because you have an embedded device that needs stuff not supported by the "generic" kernel). At best, Java becomes unstable. At worst, it just won't run. Either way, Python keeps running with a simple re-compile against the new libc. As does C++, Perl, PHP, Ruby, OCAML, ... just an example of how the open source stuff just plain works better for embedded systems work, where we are hacking operating systems to fit into various specialized devices.

- Badtux the Python-lovin' Penguin

Posted by: Badtux on June 19, 2004 12:13 AM


PaulB is right. If any COM developers have been hired at all in the United States in the past three years (something I've seen no evidence of) they're making far less than $130K. Actually, I'd be surprised if they were making more than $40K.

Posted by: Jon Meltzer on June 20, 2004 08:01 PM


industrial catalogs gas heater b2b supplies business buy industrial catalogs gift box b2b supplies business buy industrial catalogs hand tool b2b supplies business buy industrial catalogs storage container b2b supplies business buy industrial catalogs truck part b2b supplies business buy industrial catalogs water filter b2b supplies business buy industrial catalogs water pumpb2b supplies business buy industrial catalogs b2b supplies business buy

Posted by: business resources on June 21, 2004 05:33 PM


nice site ipod 20gb

Posted by: 10gb ipod on June 25, 2004 01:08 AM


nice site mini ipods

Posted by: mp3 players on June 26, 2004 12:09 AM


I'm sorry to not have noticed this article until after the spambots came in, but I wonder if the fact that MS will bring back the IE development team was brought about because of this (fearing they'll lose whatever leverage they have in the development of the web) or because by letting IE stagnate, they're starting to lose the water in the damn, and they're bringing back the boy to stick his finger into the dyke.

Posted by: Wes McGee on July 4, 2004 09:00 PM


Great site fatty lose weight with reductil and reductil uk

Posted by: reductil uk on July 6, 2004 02:23 PM


Great site fatty lose weight with reductil and reductil uk

Posted by: reductil uk on July 6, 2004 10:50 PM


Great site fatty lose weight with reductil and reductil uk

Posted by: reductil on July 8, 2004 03:06 PM


Get it up mate, it's fun!

Posted by: Viagra on July 8, 2004 08:50 PM


This will get yours up again, dude!

Posted by: Viagra on July 12, 2004 03:09 AM


It gets yours up to the top dude! The girl will enjoy it!

Posted by: cialis on July 13, 2004 07:25 AM


dental health is important to dentists and your oral wellbeing and healthy teeth

Posted by: dental plans on July 13, 2004 07:48 PM


Muppets love Viagra!

Posted by: Viagra on July 14, 2004 04:03 AM


thanks for this information

Posted by: police equipment on July 14, 2004 09:38 PM


I don't really think your thoughts are right. Maybe you need a loan?

Posted by: Loans on July 15, 2004 12:37 PM


Kontaktanzeigen are pretty cool, aren't they?

Posted by: Kontaktanzeigen mit Bild on July 16, 2004 06:41 AM


Kontaktanzeigen are pretty cool, aren't they?

Posted by: Kontaktanzeigen mit Bild on July 16, 2004 10:46 AM


Post a comment