Summary
...Wherein we look at a discussion on Unix vs. Windows religions and customs, try to make a little sense of it, and talk about designing from the outside in.
Advertisement
Okay, it turns out that I may not be the best blogger. I seem
not to have a compulsion to write all the time, so it's been far
too long since I wrote here. I'll try to do better, but I make no
guarantees.
[One digression before we get into it: Follow that link to the book above. You will find yourself on a great website for books:
Amazon Lite. It's Amazon without all the noisy fluff, and is where I go first now to buy books. Very sweet.]
Joel writes very insightful stuff on software, the process of developing software, and managing software teams. I can disagree strongly with him on things, but he's always thinking hard and well. If nothing else, when I have the chance I'm gonna steal a lot of his ideas about how to design office space for software teams. And I still throw his notes on "Guerrilla Guide to Interviewing" in front of everyone I can.
Joel talks a good deal about the cultural differences between Unix and Windows developers. He sums it up this way: "Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers." All generalizations are false, of course, but this one is less false than most. As a long-time Unix geek, I obviously can argue the advantages of the Unix preference. (For me, it's primarily composability: I can use pipes and the like to put combine useful things to do new useful things, which is really hard with GUI-based programs; see my rant on ant.) And I have a lot of respect for the idea that non-programmers aren't programmers, and need things they can understand. (Composing stuff together is a form of programming, and non-programmers aren't programmers, if you can believe it.)
His primary example is Eric's rule that "Silence is Golden". Basically it says that programs shouldn't be chatty when they're doing what they should do.
If he hadn't cited this particular example you might not be reading this. You see, I suggested this rule to Eric, so I feel particularly responsible. At the time I had been using a program that printed out about 30 lines of verbosity of "Look what I'm up to now!" After the umpteenth time I ran it, I was pretty annoyed at being told stuff that only mattered to someone debugging that program. In other words, it was using up a lot of my limited information bandwidth telling me stuff that mattered to only one person who wasn't me. So I had this on my mind.
The fundamental difference here is that a text-based program has exactly one output channel -- characters on the screen. This makes that space extremely valuable, and therefore not be wasted. A GUI program can spin its state in one text line so it doesn't use up much visual space and is easy to ignore. A screen program has no place to put lower-priority messages.
Joel is right that this is a cultural prejudice, but it's built on unvarnished experience in this ecosystem. Just like the Windows prejudice in favor of "more usability for Mom" is built on a coherent reality that is vital.
Joel himself falls victim to the arrogance of cultural familiarity that he accuses Eric of. Consider this:
When Raymond points out that the CSV format is inferior to the /etc/passwd format, he's trying to score points for Unix against Windows, but, you know what? He's right. /etc/passwd is easier to parse than CSV, and if you read this book, you'll know why, and you'll be a better programmer.
Maybe Eric is pointing this out because it is easier, not to score points against Windows. He also says that self-righteousness is more common in the Unix culture, which shows a certain blindness that comes from being more likely to treat self-righteousness on your own side as just a statement of truth.
Of course, Eric doesn't help himself by having a certain righteous tone himself. You can't read it without feeling that you are thought to be at the feet of a kindly guru, as the picture on the cover makes clear.
Joel almost gets to the meat of things when he talks about Apple and OS X. The years of inability of the Unix market to spread on the desktop have nothing to do, really, with having command line programs and readable text-based configuration files. This are not hindrances, but the cultural prejudice against limiting programmers is. OS X proves that you can put a good GUI on this stuff — Apple's administration GUI is far better than anything Windows can muster. (If you want to prove it to yourself, try setting up wireless cards with encryption on Windows vs. OS X. Oy.) The X11 approach of "Make no choices: enable them" is fundamentally flawed. The world needs a common, clear understanding of how a button works much more than it needs a dozen different buttons, each with comparative virtues. Designing without applying the arrogance of taste is a Really Bad Idea.
RMI took a better approach. Ann Wollrath first designed what users needed (here "users" means "programmers using RMI"). The mechanisms were internally well designed, but not exposed. Over time more of the internals get opened up to experts who need more than most users. This gives the priority to the 80% most common uses, and when it comes time to expose underpinnings, you know why and for whom. The X11 approach starts building from the bottom up rather than the outside in. You have to guess everything anyone might want to do at every level, making each level a slow and careful slog. After years and years you finally may get to where someone can use what you've done. The RMI approach makes you usable now, and lets you expose what actual experience shows you need to expose, by which time you also know better how people want to use it.
This approach is a much more powerful and productive way to build tools.
Joel says that Eric's book rises above the culturally superior tone, and I agree. Although to be fair, Eric's book is precisely trying to teach the culture, so I think it's fair to believe in it strongly in that context. Still, I might add that Joel's review also rises above its cultural biases. As usual, Joel is worth a good read.
Yes, lines of "look what I'm up to now" is annoying. But surely the solution is not to output nothing at all! A one line summary is good feedback.
Take the cp command in unix, which outputs its progress. I assume it does this because overwriting files is a permanent operation and users need some sort of feedback. Try working with a silent cp to experience the spooky feeling of 'what did I just do?'.
> Take the cp command in unix, which outputs its progress.
Um, not by default. Most commercial Unixes set up user accounts to alias "cp" to "cp -i" (and similarly for mv).
As for Joel's article ... well, he has some points about Unix programmers being out-of-touch with the average user, although I'd agree the subtext of "Windows programmers care about 99.999% of the population" is kind of overblown. Otherwise, why are there so many books and courses on using Windows/Word/Excel/etc? I suspect a lot of Windows programmers are primarily in touch with what makes an impressive demo ...
Yes, Joel does make some good points but my spider-sense started tingling when he claimed that the Windows-way was about usability, "usability uber alles" in fact. Being a long time Mac and usability weenie that just set my teeth on edge.
Later on there is some hand-waving about how the Windows way is in fact one and the same as the Mac way but I remain unconvinced, especially as little distinction was made between pre- and post- Stepwise Macs which would obviously blur his unix/non-unix distinctions.
So, having been a Mac OS X/Unix guy for the last few years I had to stop in the middle of his article and take stock because he was coming from a completely different direction to me: in particular the comment that you can't put a good GUI on Unix, which Gnome, Apple, Tivo, Google etc. have proved wrong.
The difference in the UNIX and Windows culture is presumably based on UNIXs background as a student and research platform (dunno whats wrong just reboot it) and Microsofts attempt (strongest I can put it) to be an appliance for people for whom a PC is just a tool to accomplish something else thats actually important ("just tell me when you're done, so I know".)
Where a Windows application isnt smart enough to send its messages under the covers to other applications, it must surface with a screen message. In that respect, every message that appears on screen in Windows (beyond Okay, Im done) represents a divergence from the Windows culture.
On the other hand, any UNIX applications that operate in dead silence (even under the covers) are difficult to tune or troubleshoot. In that respect, they are only suitable for one-off student or research programs or for simple command-line utilities. My suspicion is that this is why UNIX is under constant threat of obsolescence. A cultural problem? Yes, and one that could easily be solved perhaps by the Mac
> The difference in the UNIX and Windows culture is > presumably based on UNIXs background as a student and > research platform (dunno whats wrong just reboot it) > and Microsofts attempt (strongest I can put it) to be an > appliance for people for whom a PC is just a tool to > accomplish something else thats actually important ("just > tell me when you're done, so I know".) > > Where a Windows application isnt smart enough to send its > messages under the covers to other applications, it must > surface with a screen message. In that respect, every > message that appears on screen in Windows (beyond Okay, > Im done) represents a divergence from the Windows > culture. > > On the other hand, any UNIX applications that operate in > dead silence (even under the covers) are difficult to tune > or troubleshoot. In that respect, they are only suitable > for one-off student or research programs or for simple > command-line utilities. My suspicion is that this is why > UNIX is under constant threat of obsolescence. A cultural > problem? Yes, and one that could easily be solved > perhaps by the Mac
Given that Linux is considered a flavor of Unix, I hope it's not too late before Weta Digital, Amazon, Dreamworks, NASA, Google and others realize that they are running their businesses on an OS that is suitable only for one-off student or research programs for command line utilities. Or that the entire foundation of their businesses is under constant threat of obsolescence. Not that any other OS faces the obsolescence threat.
I guess if Return of the King looks like crap, we know the real reason why now.
Also, usually when I have the "I don't know what's wrong just reboot it" moments, it is on my Windows box. My Linux box at home doesn't suffer from this problem. I don't think I've ever met a serious Unix user that was of the "I dunno what's wrong reboot it" camp. In fact, that is the windows 'feature' that most of those sorts of people really despise. At least that has been my experience.
And any application, period, that runs dead silent even under the covers is problematic to troubleshoot or tune. I've had much greater problems with this on Windows boxes, mainly because people aren't in the habit of screen capturing every error that comes up in a windows program. It's not that the information isn't ever surfaced, it's that it is surfaced in a manner that is very hard to send off to the people that can do something about the problem. If more windows programs did better logging, I would have a much easier time troubleshooting them.
I thought this was one of Joel's weaker articles. Like David, I felt a strange warning tingle, but it was when I read this: Anything you can do from the Windows user interface can also be accomplished using a programming interface callable from any reasonable programming language. That made me think either he is a Microsoft insider or hasn't really programmed Windows. Try doing these things with the Windows API: move icons on the desktop, set up wireless encryption (and you thought it was fun with the UI), find out the manufacturer and model of your hard drive, automate another application (one that doesn't support COM Automation, I mean), detect whether an optical device can write CDs and/or DVDs, write CDs using IMAPI, change the screen resolution, redetect/disable/enable hardware, etc. Once you get your app doing all these things, make sure it works on Windows 95-98, Me, XP, NT, and 2K.
More importantly, I think Joel exaggerates the cultural characteristics of both Windows and Linux developers to a ridiculous degree. I guess this is to try to provide better relief for the points he is trying to drive home, but to me it results in doubling the strawman effect.
I do think there is more of a culture on the Windows platform of hiding ideas and/or code, though. People seem more afraid that others will "steal" them, even if they are not of financial import. On several (not all) occassions when I have asked other Windows developers how they solved a particular perncicious problem, I have encountered resistence to even give up clues or hints, much less source code. I haven't got as much experience in the Unix or Linux world, but I would imagine that wouldn't jibe with the open source philosophy and so would be much less the norm.
By the way and somewhat tangentially, relative to the ease (or capability) of doing everything in the API that you can do with the mouse, Raymond Chen has an amusing rant from the Microsoft OS writer's point of view here: http://blogs.gotdotnet.com/raymondc/commentview.aspx/82a64761-2c6c-4f2e-b567-4fd9b160e7ac, where he argues that people using undocumented methods to solve problems is the cause of a lot of cruft in the Windows APIs and that a lot of goofy stuff is there "...because some random app or other decided to cheat and bypass the documented way of doing things." But he misses or ignores the point that over the history of Windows there have always been plenty of cases where there was no "documented way of doing [particular] things." Since there is no source code available, what alternatives are there?
It's slightly off-topic, but there's an interesting article in this month's American Scientist, called Qwerks of History, that addresses why some technologies persist and others don't:
Hi, Ken: You raise an interesting point wrt. X11 and RMI toward the end of your post. But didn't the two systems have drastically different goals wrt. market share capture and timescales. The former was within an academic environment with semi guaranteed funding, and the latter needed to grab mind-share fast. Wouldn't you say that these external factors had more to do with the approaches taken than something intrinsic wrt. the designers' ability or intent here..?
Previous Topic
