I Was a Teenage Thought Policeman

It’s a dirty job, but somebody’s gotta do it!

By Chris Espinosa, Apple Computer, MacTech Magazine Regular Contributor

Two months ago, MacTech published a letter from a reader talking about “good” and “bad” programming practices, calling the editors of this magazine the “Thought Police.” The editors replied with something to the effect that somebody has to do it.

This issue crops up every few years, and people get really emotional about it. A lot of programmers naturally rebel at the thought of having Somebody Else tell them how they should write their code. The favorite historical Thought Police issue centers around the user interface, but error handling, C coding style, object design methodology have all seen conflict between some who would seek to impose standards and others who resist them.

I’m one of the people occasionally accused of starting all this in the Macintosh community. I wrote several of the early versions of the Macintosh Human Interface Guidelines, which got credited for creating the consistency among applications in the Mac system, but also roundly blamed for being the original Thought Police dictum of Macintosh political correctness.

The personal computer application software industry was really in its infancy when Mac development started in 1982, and developers really didn’t know what elements made a software product a hit. Many apps were still “turn-key,” meaning you started the computer directly into the app. Applications were free to take over the machine. Hard disks were rare, and floppies usually didn’t hold more than two or three applications. So developers valued the individuality of their application, and in many cases considered a unique menu structure to be a major competitive advantage.

Apple proposed, pretty audaciously, that all applications should use a consistent menu command structure, and even more audaciously, use one that Apple designed. Even better, Apple built the interface software right into the ROM of the machine - it was in fact more difficult to use your own, familiar, already coded interface software than it was to knuckle under and do things Apple’s way.

Reactions to this ranged from delight to umbrage. Some people conceptually bought the idea of consistency from application to application, and were enthralled by the amount of graphics, interface, and utility code already written for them, but others worried how they’d differentiate their products if all applications worked the same.

There was a pretty deep division of opinion over this. Many praised Apple for being daring and doing the Right Thing, and defended the guidelines. Others resented the fact that it was so hard to not do things the Macintosh way, and condemned the platform for being proscriptive. There was a little bit of a war between these forces, and most people assumed that Apple was on the side of the consistency zealots.

And I’m certain there were influential people at Apple who did some righteous bashing of inconsistent applications. I remember an early database, MacLion, which was a bad port of a DOS application, right down to the 24-by-80 monospaced scrolling text window. Boy, it was ugly. It eventually lost in the marketplace. Apple also spent a lot of time working with major DOS application vendors to get them to “get it” about the graphic user interface. Lotus received a lot of personal attention from Apple for their Jazz product, and later 1-2-3 for Mac.

But the folklore that has come down through the years is that Apple defended the purity of the interface by punishing the developers who built applications that broke the rules. And that’s just not true. The rules were vague; they were revised several times over the first five years; we broke the rules ourselves (starting early, with MacPaint); and to tell you the truth, we were so desperate for software that we even put that ugly, DOSish MacLion on our poster of the first 100 apps.

The truth is that the punishment for inconsistency came from the Mac community itself. Magazine reviewers and pundits were the first to appreciate the consistency and simplicity of Mac applications, especially in contrast with the growing mess in the DOS world. Influential users and purchasers followed suit. Programs with inconsistent interfaces did suffer; but they suffered at the hands of the marketplace, not of a dictatorial Apple.

By 1991, Apple’s efforts around human interface were pretty much limited to advice, pronouncements, and leading by example (such as in System 7’s outline-expansion arrows and Drag and Drop). Users and editors still screamed at developers, and developers at each other, oddly turning the original fear on its head: developers claimed their application was superior because it was more conformant to the standard, not unique and different. The interface grew and changed, with some styles becoming popular (like windoids) and others just not making it (such as the use of Microsoft-style boxes to group elements in a dialog box). The idea that there were Thought Police, though, was so thoroughly ingrained in the Mac community that the thought police didn’t need to exist anymore: developers just did the right thing the majority of the time, but still took risks once in a while to push the interface forward.

There’s always a balance between freedom and responsibility. Programmers want to be free, but in order for the whole community to be successful, programmers have to be responsible, and hold up their end. Keeping the interface consistent, reducing bugs by doing correct error handling, avoiding inappropriate system hacks, and not being predatory of competitive applications are some pretty important responsibilities. Doing these well improves the quality of life for all Mac users, and supports the platform sales, creating a larger opportunity for software authors.

Scott Boyd is perfectly right: somebody has to be the thought police. The beauty of the last ten years of Macintosh development is that everybody is the Thought Police. You’ve got a lot of people looking over your shoulder to keep you straight, but there’s no actual bogeyman there to beat you up if you get creative.