Skip to content

Instantly share code, notes, and snippets.

@murtyjones
Created September 10, 2019 13:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save murtyjones/66238690db5bb34d7aa749d51158f0a4 to your computer and use it in GitHub Desktop.
Save murtyjones/66238690db5bb34d7aa749d51158f0a4 to your computer and use it in GitHub Desktop.
> This great church is an incomparable work of art. There is neither aridity nor confusion in the tenets it sets forth. . . .
> is the zenith of a style, the work of artists who had
understood and assimilated all their predecessors ' successes,
in complete possession of the techniques of their times, but
using them without indiscreet display nor gratuitous feats
of skill.
> It was Jean d'Orbais who undoubtedly conceived the
general plan of the building, a plan which was respected,
at least in its essential elements, by his successors. This is
one of the reasons for the extreme coherence and unity of
the edifice.
> – REIMS CATHEDRAL GUIDEBOOK'
# Aristocracy, Democracy, and System Design
## Conceptual Integrity
Most European cathedrals show differences in plan or architec-
tural style between parts built in different generations by different
builders. The later builders were tempted to ''improve'' upon the
designs of the earlier ones, to reflect both changes in fashion and
differences in individual taste. So the peaceful Norman transept
abuts and contradicts the soaring Gothic nave, and the result pro-
claims the pridefulness of the builders as much as the glory of
God.
Against these, the architectural unity of Reims stands in glori-
ous contrast. The joy that stirs the beholder comes as much from
the integrity of the design as from any particular excellences. As
the guidebook tells, this integrity was achieved by the self-abne-
gation of eight generations of builders, each of whom sacrificed
some of his ideas so that the whole might be of pure design. The
result proclaims not only the glory of God, but also His power to
salvage fallen men from their pride.
Even though they have not taken centuries to build, most
programming systems reflect conceptual disunity far worse than
that of cathedrals. Usually this arises not from a serial succession
of master designers, but from the separation of design into many
tasks done by many men.
I will contend that conceptual integrity is the most important
consideration in system design. It is better to have a system omit
certain anomalous features and improvements, but to reflect one
set of design ideas, than to have one that contains many good but
independent and uncoordinated ideas. In this chapter and the next
two, we will examine the consequences of this theme for program-
ming system design:
- How is conceptual integrity to be achieved?
- Does not this argument imply an elite, or aristocracy of archi-
tects, and a horde of plebeian implementers whose creative
talents and ideas are suppressed?
## Achieving Conceptual Integrity
- How does one keep the architects from drifting off into the
blue with unimplementable or costly specifications?
- How does one ensure that every trifling detail of an architec-
tural specification gets communicated to the implementer,
properly understood by him, and accurately incorporated into
the product?
## Achieving Conceptual Integrity
The purpose of a programming system is to make a computer easy
to use. To do this, it furnishes languages and various facilities that
are in fact programs invoked and controlled by language features.
But these facilities are bought at a price: the external description
of a programming system is ten to twenty times as large as the
external description of the computer system itself. The user finds
it far easier to specify any particular function, but there are far
more to choose from, and far more options and formats to remem-
ber.
Ease of use is enhanced only if the time gained in functional
specification exceeds the time lost in learning, remembering, and
searching manuals. With modern programming systems this gain
does exceed the cost, but in recent years the ratio of gain to cost
seems to have fallen as more and more complex functions have
been added. I am haunted by the memory of the ease of use of the
IBM 650, even without an assembler or any other software at all.
Because ease of use is the purpose, this ratio of function to
conceptual complexity is the ultimate test of system design. Nei-
ther function alone nor simplicity alone defines a good design.
This point is widely misunderstood. Operating System/360 is
hailed by its builders as the finest ever built, because it indisputa-
bly has the most function. Function, and not simplicity, has al-
ways been the measure of excellence for its designers. On the
other hand, the Time-Sharing System for the PDP-10 is hailed by
its builders as the finest, because of its simpHcity and the spareness
44 Aristocracy, Democracy, and System Design
of its concepts. By any measure, however, its function is not even
in the same class as that of OS/360. As soon as ease of use is held
up as the criterion, each of these is seen to be unbalanced, reaching
for only half of the true goal.
For a given level of function, however, that system is best in
which one can specify things with the most simplicity and
straightforwardness. Simplicity is not enough. Mooers's TRAC
language and Algol 68 achieve simplicity as measured by the num-
ber of distinct elementary concepts. They are not, however,
straightforward. The expression of the things one wants to do often
requires involuted and unexpected combinations of the basic facil-
ities. It is not enough to learn the elements and rules of combina-
tion; one must also learn the idiomatic usage, a whole lore of how
the elements are combined in practice. Simplicity and straightfor-
wardness proceed from conceptual integrity. Every part must re-
flect the same philosophies and the same balancing of desiderata.
Every part must even use the same techniques in syntax and
analogous notions in semantics. Ease of use, then, dictates unity
of design, conceptual integrity.
Aristocracy and Democracy
Conceptual integrity in turn dictates that the design must proceed
from one mind, or from a very small number of agreeing resonant
minds.
Schedule pressures, however, dictate that system building
needs many hands. Two techniques are available for resolving this
dilemma. The first is a careful division of labor between architec-
ture and implementation. The second is the new way of structur-
ing programming implementation teams discussed in the previous
chapter.
The separation of architectural effort from implementation is
a very powerful way of getting conceptual integrity on very large
projects. I myself have seen it used with great success on IBM's
Stretch computer and on the System/360 computer product line.
Aristocracy and Democracy 45
I have seen it fail through lack of application on Operating Sys-
tem/360.
By the architecture of a system, I mean the complete and de-
tailed specification of the user interface. For a computer this is the
programming manual. For a compiler it is the language manual. For
a control program it is the manuals for the language or languages
used to invoke its functions. For the entire system it is the union
of the manuals the user must consult to do his entire job.
The architect of a system, like the architect of a building, is
the user's agent. It is his job to bring professional and technical
knowledge to bear in the unalloyed interest of the user, as opposed
to the interests of the salesman, the fabricator, etc.^
Architecture must be carefully distinguished from implemen-
tation. As Blaauw has said, ''Where architecture tells what hap-
pens, implementation tells how it is made to happen."^ He gives
as a simple example a clock, whose architecture consists of the
face, the hands, and the winding knob. When a child has learned
this architecture, he can tell time as easily from a wristwatch as
from a church tower. The implementation, however, and its real-
ization, describe what goes on inside the case — powering by any
of many mechanisms and accuracy control by any of many.
In System/360, for example, a single computer architecture is
implemented quite differently in each of some nine models. Con-
versely, a single implementation, the Model 30 data flow, memory,
and microcode, serves at different times for four different architec-
tures: a System/360 computer, a multiplex channel with up to 224
logically independent subchannels, a selector channel, and a 1401
computer.*
The same distinction is equally applicable to programming
systems. There is a U.S. standard Fortran IV. This is the architec-
ture for many compilers. Within this architecture many imple-
mentations are possible: text-in-core or compiler-in-core,
fast-compile or optimizing, syntax-directed or ad-hoc. Likewise
any assembler language or job-control language admits of many
implementations of the assembler or scheduler.
46 Aristocracy, Democracy, and System Design
Now we can deal with the deeply emotional question of aris-
tocracy versus democracy. Are not the architects a new aristocracy,
an intellectual elite, set up to tell the poor dumb implementers
what to do? Has not all the creative work been sequestered for this
elite, leaving the implementers as cogs in the machine? Won't one
get a better product by getting the good ideas from all the team,
following a democratic philosophy, rather than by restricting the
development of specifications to a few?
As to the last question, it is the easiest. I will certainly not
contend that only the architects will have good architectural ideas.
Often the fresh concept does come from an implementer or from
a user. However, all my own experience convinces me, and I have
tried to show, that the conceptual integrity of a system determines
its ease of use. Good features and ideas that do not integrate with
a system's basic concepts are best left out. If there appear many
such important but incompatible ideas, one scraps the whole sys-
tem and starts again on an integrated system with different basic
concepts.
As to the aristocracy charge, the answer must be yes and no.
Yes, in the sense that there must be few architects, their product
must endure longer than that of an implementer, and the architect
sits at the focus of forces which he must ultimately resolve in the
user's interest. If a system is to have conceptual integrity, someone
must control the concepts. That is an aristocracy that needs no
apology.
No, because the setting of external specifications is not more
creative work than the designing of implementations. It is just
different creative work. The design of an implementation, given an
architecture, requires and allows as much design creativity, as
many new ideas, and as much technical brilliance as the design of
the external specifications. Indeed, the cost-performance ratio of
the product will depend most heavily on the implementer, just as
ease of use depends most heavily on the architect.
There are many examples from other arts and crafts that lead
one to believe that discipline is good for art. Indeed, an artist's
What Does the Implementer Do While Waiting? 47
aphorism asserts, 'Torm is liberating/' The worst buildings are
those whose budget was too great for the purposes to be served.
Bach's creative output hardly seems to have been squelched by the
necessity of producing a limited-form cantata each week. I am sure
that the Stretch computer would have had a better architecture
had it been more tightly constrained; the constraints imposed by
the System/360 Model 30's budget were in my opinion entirely
beneficial for the Model 75's architecture.
Similarly, I observe that the external provision of an architec-
ture enhances, not cramps, the creative style of an implementing
group. They focus at once on the part of the problem no one has
addressed, and inventions begin to flow. In an unconstrained im-
plementing group, most thought and debate goes into architectural
decisions, and implementation proper gets short shrift.^
This effect, which I have seen many times, is confirmed by
R. W. Conway, whose group at Cornell built the PL/C compiler
for the PL/I language. He says, ''We finally decided to implement
the language unchanged and unimproved, for the debates about
language would have taken all our effort."^
What Does the Implementer Do While Waiting?
It is a very humbling experience to make a multimillion-dollar
mistake, but it is also very memorable. I vividly recall the night
we decided how to organize the actual writing of external specifi-
cations for OS/360. The manager of architecture, the manager of
control program implementation, and I were threshing out the
plan, schedule, and division of responsibilities.
The architecture manager had 10 good men. He asserted that
they could write the specifications and do it right. It would take
ten months, three more than the schedule allowed.
The control program manager had 150 men. He asserted that
they could prepare the specifications, with the architecture team
coordinating; it would be well-done and practical, and he could do
it on schedule. Furthermore, if the architecture team did it, his 150
men would sit twiddling their thumbs for ten months.
48 Aristocracy, Democracy, and System Design
To this the architecture manager responded that if I gave the
control program team the responsibiUty, the result would not in
fact be on time, but would also be three months late, and of much
lower quality. I did, and it was. He was right on both counts.
Moreover, the lack of conceptual integrity made the system far
more costly to build and change, and I would estimate that it
added a year to debugging time.
Many factors, of course, entered into that mistaken decision;
but the overwhelming one was schedule time and the appeal of
putting all those 150 implementers to work. It is this siren song
whose deadly hazards I would now make visible.
When it is proposed that a small architecture team in fact
write all the external specifications for a computer or a program-
ming system, the implementers raise three objections:
• The specifications will be too rich in function and will not
reflect practical cost considerations.
• The architects will get all the creative fun and shut out the
inventiveness of the implementers.
• The many implementers will have to sit idly by while the
specifications come through the narrow funnel that is the
architecture team.
The first of these is a real danger, and it will be treated in the
next chapter. The other two are illusions, pure and simple. As we
have seen above, implementation is also a creative activity of the
first order. The opportunity to be creative and inventive in imple-
mentation is not significantly diminished by working within a
given external specification, and the order of creativity may even
be enhanced by that discipline. The total product will surely be.
The last objection is one of timing and phasing. A quick an-
swer is to refrain from hiring implementers until the specifications
are complete. This is what is done when a building is constructed.
In the computer systems business, however, the pace is
quicker, and one wants to compress the schedule as much as
possible. How much can specification and building be overlapped?
What Does the Implementer Do While Waiting? 49
As Blaauw points out, the total creative effort involves three
distinct phases: architecture, implementation, and realization. It
turns out that these can in fact be begun in parallel and proceed
simultaneously.
In computer design, for example, the implementer can start as
soon as he has relatively vague assumptions about the manual,
somewhat clearer ideas about the technology, and well-defined
cost and performance objectives. He can begin designing data
flows, control sequences, gross packaging concepts, and so on. He
devises or adapts the tools he will need, especially the record-
keeping system, including the design automation system.
Meanwhile, at the realization level, circuits, cards, cables,
frames, power supplies, and memories must each be designed,
refined, and documented. This work proceeds in parallel with
architecture and implementation.
The same thing is true in programming system design. Long
before the external specifications are complete, the implementer
has plenty to do. Given some rough approximations as to the
function of the system that will be ultimately embodied in the
external specifications, he can proceed. He must have well-defined
space and time objectives. He must know the system configuration
on which his product must run. Then he can begin designing
module boundaries, table structures, pass or phase breakdowns,
algorithms, and all kinds of tools. Some time, too, must be spent
in communicating with the architect.
Meanwhile, on the realization level there is much to be done
also. Programming has a technology, too. If the machine is a new
one, much work must be done on subroutine conventions, super-
visory techniques, searching and sorting algorithms.^
Conceptual integrity does require that a system reflect a single
philosophy and that the specification as seen by the user flow from
a few minds. Because of the real division of labor into architecture,
implementation, and realization, however, this does not imply that
a system so designed will take longer to build. Experience shows
the opposite, that the integral system goes together faster and
50 Aristocracy, Democracy, and System Design
takes less time to test. In effect, a widespread horizontal division
of labor has been sharply reduced by a vertical division of labor,
and the result is radically simplified communications and im-
proved conceptual integrity.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment