The greater problem of psychology only became clear to me
after spending three days at a Macintosh developer conference in 2000.
It was a very enlightening experience to be immersed in a programming
culture with assumptions diametrically opposed to those of the Unix
world.
Macintosh programmers are all about the user experience.
They're architects and decorators. They design from the outside in,
asking first “What kind of interaction do we want to
support?” and then building the application logic behind it to
meet the demands of the user-interface design. This leads to programs
that are very pretty and infrastructure that is weak and rickety. In
one notorious example, as late as Release9 the MacOS memory manager
sometimes required the user to manually deallocate memory by manually
chucking out exited but still-resident programs. Unix people are
viscerally revolted by this kind of mal-design; they don't understand
how Macintosh people could live with it.
By contrast, Unix people are all about infrastructure. We are
plumbers and stonemasons. We design from the inside out, building
mighty engines to solve abstractly defined problems (like “How
do we get reliable packet-stream delivery from point A to point B over
unreliable hardware and links?”). We then wrap thin and often
profoundly ugly interfaces around the engines. The commands
date(1),
find(1),
and
ed(1)
are notorious examples, but there are hundreds of others. Macintosh
people are viscerally revolted by this kind of mal-design; they don't
understand how Unix people can live with it.
Both design philosophies have some validity, but the two camps
have a great deal of difficulty seeing each other's points. The
typical Unix developer's reflex is to dismiss Macintosh software as
gaudy fluff, eye-candy for the ignorant, and to continue
building software that appeals to other Unix developers. If end-users
don't like it, so much the worse for the end users; they will come
around when they get a clue.
In many ways this kind of parochialism has served us well. We
are the keepers of the Internet and the World Wide Web. Our software
and our traditions dominate serious computing, the applications where
24/7 reliability and minimal downtime is a must. We really are
extremely good at building solid infrastructure; not perfect by any
means, but there is no other software technical culture that has
anywhere close to our track record, and it is one to be proud
of.
The problem is that we increasingly face challenges that demand
a more inclusive view. Most of the computers in the world don't live
in server rooms, but rather in the hands of those end users. In early
Unix days, before personal computers, our culture defined itself
partly as a revolt against the priesthood of the mainframes, the
keepers of the big iron. Later, we absorbed the power-to-the-people
idealism of the early microcomputer enthusiasts. But today
we
are the priesthood;
we
are the people who run the networks and the big iron. And our
implicit demand is that if you want to use our software, you must
learn to think like us.
In 2003, there is a deep ambivalence in our attitude — a
tension between elitism and missionary populism. We want to reach and
convert the 92% of the world for whom computing means games and
multimedia and glossy GUI interfaces and (at their most technical)
light email and word processing and spreadsheets. We are spending
major effort on projects like GNOME and KDE designed to give Unix a
pretty face. But we are still elitists at heart, deeply reluctant and
in many cases unable to identify with or listen to the needs of the
Aunt Tillies of the world.
To non-technical end users, the software we build tends to be
either bewildering and incomprehensible, or clumsy and condescending,
or both at the same time. Even when we try to do the
user-friendliness thing as earnestly as possible, we're woefully
inconsistent at it. Many of the attitudes and reflexes we've
inherited from old-school Unix are just wrong for the job. Even when
we want to listen to and help Aunt Tillie, we don't know how —
we project our categories and our concerns onto her and give her
‘solutions’ that she finds as daunting as her
problems.
We can turn aside from this; we can remain a priesthood
appealing to a select minority of the best and brightest, a geek
meritocracy focused on our historical role as the keepers of the
software infrastructure and the networks. But if we do this, we will
very likely go into decline and eventually lose the dynamism that has
sustained us through decades. Someone else will serve the people;
someone else will put themselves where the power and the money are, and
own the future of 92% of all software. The odds are, whether that
someone else is
Microsoft or not,
that they will do it using practices and software we don't much
like.
Tellingly, the Macintosh culture has begun to converge with ours
— MacOS X has Unix underneath, and in 2003 Mac developers
are (albeit with a struggle in some cases) making the mental
adjustment to learn the infrastructure-focused virtues of Unix.
Our challenge will be, reciprocally, to embrace the user-centered
virtues of the Macintosh.
There are other signs that the Unix culture is shedding its
insularity as well. One is the convergence that seems to be going on
between the Unix/open-source community and the movement called
“agile programming”.[164] We noted in Chapter4 that Unix programmers have seized happily
on the concept of refactoring, one of the preoccupations of the
agile-programming thinkers. Refactoring, and other agile concepts
like unit-testing and design around stories, seem to articulate and
sharpen practices that have heretofore been widespread but only
implicit in the Unix tradition. The Unix tradition, on the other hand,
can bring groundedness and the lessons of long experience to the
agile-programming party. As open-source software gains market share
it is even conceivable that these cultures will fuse, much as the
old-time Internet and early Unix cultures did after 1980.
