|
In Beyond This Horizon Robert Heinlein identified the job of the future as "encyclopaedic
synthesist"–someone who could absorb knowledge from many different
fields and meld it to produce new insights.
Personally I find the job of Know-it-All-In-Chief extremely attractive,
and I suspect both Heinlein himself and a lot of his readers do
as well. However the more I think about it, the more I think Heinlein
got it wrong.
Attractive as the notion of an encyclopaedic synthesist is, it
goes against the fundamental grain of the way humans accumulate
and use knowledge. We’re social animals who work best in groups.
Most of our advances in knowledge have come from a combination
of specialization and cooperation. An Einstein or a Newton develops a fundamental insight and then legions of
scientists, engineers, and ordinary people develop and refine
it and turn it into things that are useful.
There’s certainly a problem of becoming too specialized so that
knowledge from different areas isn’t being combined and used effectively.
That’s one of the reasons Analog runs fact articles; to provide cross-pollination. However, better
communication is probably a better way of handling the problem
than trying to create a new breed of metaspecialist.
The Internet is a case in point. The Internet, and its mutant
offspring the World Wide Web, are coming ever closer to meeting
the ideal of making all the world’s knowledge available to anyone
who wants it. Already the volume of information out there is astounding.
Better yet, a lot of it is written as tutorials to explain whatever
it is to nonspecialists. And best of all, the Internet and the
Web serve as locator services for experts in nearly anything you
can think of. You may not know the answer but you can find someone
who does by hitting the Web or the Internet newsgroups.
There are still a lot of problems with the Internet as a source
of information. For one thing the search facilities are lousy.
Even the most sophisticated search engines aren’t very sophisticated
and you waste a lot of time wading through stuff you’re not interested
in. Worse, if you can’t think of the magic words or phrases people
have used, you often don’t find anything. And if the volume of
information is astounding, the volume of junk, misinformation,
pornography, weird political tracts and other stuff is even more astounding.
Still, I think the principle is clear. While we will undoubtedly
have people who are especially good synthesists, most of us will
do our own synthesizing with the help of knowledge stored on-line.
So what will be the job of the future? On reflection, I think
Heinlein got it backwards. The job of the future will not be combining
things, it will be breaking things apart.
What led to this insight was Linux. As a frequent writer about
Linux topics, and as a columnist for the online magazine LinuxWorld,
I think a lot about Linux these days. It’s a very interesting
thing to think about, too.
Linux is a clone of the Unix operating system. What’s different
about it is the way it was made.
Linux wasn’t done by a company. It started as the personal project
of a student in Finland named Linus Torvalds (hence "Linux") and
was perfected by a group of volunteers all over the world tied
together by the Internet. Linus remains in overall control, and
there are teams working on specific areas, but anyone is free
to contribute. Kind of software stone soup.
When a new feature or utility is developed for Linux, it is released
and what follows is a Darwinian winnowing-out process. People make suggestions, improvements,
or come up with complete new versions of the feature or utility.
Eventually something emerges that combines the best features of
the candidates and becomes the standard piece of software for
doing that job.
Linux itself is taking the computing world by storm. Tens of thousands
of people are installing this free operating system on their computers,
in many cases replacing Microsoft Windows. Which is nifty, but
for my purposes the Open Source model, under which Linux was developed,
is even more interesting.
Open Source is a concept that owes its present incarnation to
a computer scientist named Richard Stallman. Stallman believes
that software should be open and freely available and to put his
money where his mouth is, Stallman and a large group of like-minded
individuals created the GNU project to develop and distribute
free software. (GNU stands for GNU is Not Unix, an example of
recursive naming and programmer humor.) One of the things the
GNU project developed as the Open Source software license, sometimes
called "copyleft." The idea is simple. You can use the software,
and distribute it to anyone free. But you must include the source
code (the human readable program) with the distribution. And if you modify the program in any way you have to distribute the source code
to your modifications.
Intentionally or not, Open Source has created a whole new way
of developing software. It affects not just the software, but
the process by which the work of creating it is done. A successful
Open Source project is near-perfect example of Anarchy in action.
Anarchy (big-A. The small-a version of anarchy is something else
again) replaces formal structure with voluntary cooperation. As
a political theory it is somewhat deader than a doornail–an object
so dead 99 people out of a hundred can’t even tell you what a
doornail was. The problems of replacing government, business and
everything else with a network of voluntarily cooperating enterprises
is seen as insurmountable and the nineteenth-century Anarchists
didn’t help their case by trying to substitute assassination for
party politics.
But while Anarchy presents insurmountable problems for governing
a society, it is one of the best systems ever developed for getting
the absolute best out of a group of talented, motivated people.
And that’s an increasing problem. More and more the old ways of
motivating people are failing to meet the needs of our post-industrial
society because increasingly we need not merely performance, but
superb performance if we are to compete and continue to make life
better for everyone.
Slavery doesn’t work. It’s economically inefficient because (among
many other reasons) the productivity is low and the quality of
output is lousy. You can get gangs of slaves to pick cotton, but
you can pick a lot more cotton a lot cheaper with a modern cotton
picking machine. But you can’t build cotton pickers with slave
labor, not if you want to be competitive.
The old industrial system has weaknesses as well. In the old days
the primary motivators of workers were money and fear. If you
were good you got paid and if you were bad you got fired. The
problem with those motivators is that they don’t work all that
well. You can get a functioning assembly line that way but you
don’t get a highly motivated, competitive work force.
Leaving aside some changes on the industrial system, that brings
us to an Open Source project. The key person in an Open Source
project is the project leader. This usually self-appointed individual
is the dictator who makes the key decisions for the project. Typically
the project leader is backed up by volunteer programmers who support
the project by writing code. Each one usually writes just a section
of the program and the project leader makes sure they are combined
into something useful.
Of course like most absolute monarchs, the project leader isn’t
free to do anything he or she wants. Not if she wants the project
to succeed, anyway. The project leader has to convince people
to work on the project and this tends to be a self-reinforcing
proposition.
If the project leader doesn’t succeed, one of two things happens. The project
either dies or someone else picks up the idea, appoints himself/herself
project leader of a new team, and makes another run at it. It
is not unknown to have two or three groups working on the same
idea.
So if you’re the project leader, you have to keep the troops working.
But by traditional standards you’re extremely limited in the methods
you can employ. You can’t threaten to fire anyone because you
never hired them in the first place. You can’t offer them more
money because there isn’t any. You don’t even have the Silicon
Valley equivalent of money–stock options–to sling around. Basically
you only have two things you can reward people with to keep them
working on the project.
One of those things is recognition. The people who worked on Open
Source software have their names on the product. They become known
to their peers in the programming community and if they’ve done
good work they’re admired for it. Recognition of this sort is
a very powerful drug where human beings are concerned. (It is,
for example, the main reason I’m writing this column. Analog pays quite well by science fiction standards, but it’s a lot
less than the computer magazines I usually write for. On the other
hand, I didn’t grow up reading computer magazines.)
Science fiction fandom, which is almost completely run by volunteers,
has recognized this principle for decades. In SF terms it is called
"ego-boo" and it is a great motivator for people who publish fanzines,
run science fiction conventions and such.
The second great motivator in the Open Source community is the
Pinball Effect. Basically creative endeavors, whether writing
novels, painting pictures or developing software are like playing
pinball. The reward for doing it well is the chance to do it again.
Or, as the techies put it, the chance to work on something "interesting."
The most important way a project leader attracts a team is by
giving them something interesting to work on. That means a piece
of work large enough to be intrinsically interesting, but small
enough to be doable.
And this, after several times around robin hood’s barn, brings
us to the key job in the Brave New World: Decomposer-In-Chief
(or, less reverently "Head Compost Heap").
The Decomposer-In-Chief is a kind of project manager, although
he or she doesn’t necessarily run the project. The DIC’s function
is to break the job up into pieces of the appropriate size and
parcel them out to the appropriate people. This is a skill that
requires balancing the size of each piece against its intrinsic
interest and the skill level of the people you’re giving it to.
Being a Decomposer-in-Chief requires the ability to judge not
only things, but people as well. A successful DIC has to judge
the skill level and enthusiasm of the workers and know how much
of what kind of job to assign to what person. The DIC’s goal isn’t
just to get the job done. It is to get the job done to the best
possible quality with the time and resources available. The DIC
has to get the most out of each worker by making the job as interesting
and challenging as possible for that worker.
Now obviously this model works better in some kinds of enterprises
than others. It works best when the job is intellectually challenging
and can be split into independent parts which can be widely distributed
physically. But those are exactly the kind of jobs that are becoming
more important as we move into the twenty-first century.
So far Decomposer-In-Chief is an unrecognized specialty. There
are no degree programs leading to a PhDecomposer. There aren’t
even any books on how to be a good Decomposer There’s just a growing
need for people to do the job.
(Editor’s Note–This is an "Alternate Alternate View." As Jeffery
D. Kooistra indicated at the end of his last column, he is taking
this month off because of the demands on his time associated with
a major move and job change. He’ll be back, but for now, Rick
Cook, a writer familiar to Analog readers and quite adept with Alternate views in his own right,
has kindly agreed to fill in.)
|
"The Grand Decompositor: The Job of the Future" copyright 1999,
Rick Cook
|
|