Thought Policeman
Volume Number: 11
Issue Number: 4
Column Tag: Inside Info
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.