Subscribe to
Posts
Comments
NSLog(); Header Image

Joel on Blame

Joel Spolsky has posted another "Microsoft is Stupid" missive at joelonsoftware.com. Many of his points are valid, and his main point is rather lucid, but one paragraph stood out for me as a Mac user and developer.

The toss-aside paragraph comes in a section in which Joel talks about Microsoft's engineering efforts in getting old applications working on new OSes. Joel tells the story of SimCity, which relied on a hack to quickly do some things, and which broke on a newer version of Windows. Microsoft added code to Windows that preserved the old "broken" way of doing things when SimCity was active. Joel holds this up as "A Good Thing™" before launching into this:

A lot of developers and engineers don't agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It's why so few applications from the early days of the Macintosh still work.

Funny, but I remember seeing screenshots of MacPaint, MacWrite, etc. running in Classic mode when Mac OS X (Public Beta or 10.0) was released. Here's a screenshot of SuperPaint from 1993 running on Mac OS X 10.2.8. Classic mode was hailed as a pretty great way to bring even the oldest of applications along (thanks Will Scherrer).

If code is written poorly, I believe it should break. Hopefully it breaks immediately, during development, but better late than never. It's a developer's responsibility to write decent, proper code, not to cheat the system and use undocumented APIs. Apple has not been accused of using hidden APIs nearly as frequently as Microsoft has, so perhaps it's easier for Apple to remove from, add to, or otherwise modify hidden or unsupported APIs because so few of their own end-user software relies on them.

A private API is a private API. A developer takes a known risk when they implement something that's not publicly documented or supported. This risk is then passed on to an unknowing consumer. Blaming Apple (or any OS maker) for changing how unsupported, hidden, or "hacky" things work is ridiculous. The blame belongs with the developer who took a known risk in using the API to begin with.

Joel relies on one of the worst tactics for supporting a point: not supporting his point. "It's why so few applications from the early days of the Macintosh still work" is such a silly claim as to seriously damage his credibility as an observer of computing history and a purveyor of solid opinion.

For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple's official Bible of Macintosh programming, there was a tech note saying "you can't do this," they did it, and it worked, and their programs ran faster… until the next version of the OS came out and they didn't run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby.

This portion disgusts me. "Most" of these companies went out of business because Apple disallowed something it had never explicitly allowed to begin with? Please. Perhaps Joel is not saying this - he's "correct" in his vagueness by saying that the companies only went out of business, not how - but the inference is there. Furthermore, he fails to provide any sort of proof. Granted, this is not the purpose of his article - but why include "factual" information devoid of facts?

The developers chose to use an unsupported method to gain some speed. That's not "tough luck," that's a decision. I don't chalk up things I have control over to luck, and neither should Joel: it shifts blame from those who are responsible (the developers) to those who are not (the OS vendor).

Joel makes solid points in this article, but my opinion of him continues to erode with each time he takes pot shots for no real reason. Unsupported, flamebait comments such as these serve no purpose in what I hope is an otherwise upstanding editorial.

4 Responses to "Joel on Blame"

  1. Apple puts in workarounds for certain applications as well - Check out this post by Eric Schlegel of Apple:

    On Nov 7, 2003, at 1:20 PM, ....

    > Hey, perhaps in some of those cases you could introduce a time

    > delay in the code path that works around developer-induced problems.

    > Then the code would work, but there'd be a performance hit to motivate

    > the developer to fix his code. heheheActually, we do something very like that. When we introduce workarounds for a specific application, we (almost) always tie the workaround to a specific version or versions of the application - usually, the currently shipping version. So if FileBuddy version 22.4 happened to be incompatible with Mac OS 10.9, we would add a workaround that only applies to version 22.4; when you ship version 22.5, the workaround will cease to apply. We also always notify the developer of the problem that we find. That way, the developer has both the knowledge of what is needed to fix the bug, and an incentive to fix it in the next version of the application.

  2. Joel makes solid points in this article, but my opinion of him continues to erode with each time he takes pot shots for no real reason.

    I agree. I think Joel has some sound ideas and viewpoints, but his "potshots" at Unix, Java, and OO turned me off and I no longer read him. This was a interesting article and I will be commenting on it too.

  3. I think you missed the point. The issue is not application developer vs. OS vendor; it's OS vendor vs. consumers. If MS has a policy to be backward-compatible with "broken" applications, and Apple doesn't, then MS has a competitive advantage with the consumer. You can argue all you want about how justified you are to let the applications break, but the consumer won't care whose fault it is. If application A used to work on the old OS, and now doesn't, the OS gets the blame. If it happens 10 times with 10 applications, the OS gets dumped.

    Of course the right way to guard against this is to make sure applications can't call your non-public APIs, but good luck with that 🙂

    Also, there's obviously a tradeoff involved; you have to make a choice, do you want to spend your time on adding a new cool feature to your OS, or do you want to support some thirdparty jerk's broken application instead. The point is, the choice made is not based on who's fault it is that things break, but based on what the consumer would prefer.

  4. Apple does it too, August, you are right. I don't really think that they should. I understand why, and that's what Eugene talks about, but I was trying to say whether I think the practice itself is right or wrong, not good or bad (I make a distinction between those two pairs of words). It's clearly a good thing for Apple or MS to do or customers will blame the OS, you bet.

    I'm not a big fan of coddling, and putting work-arounds in the OS for third-party broken or "bad" code is coddling. The more code OS developers write, and the more special cases they put in, the more likely something will create a bug or break other things.