Created
September 10, 2019 13:45
-
-
Save murtyjones/66238690db5bb34d7aa749d51158f0a4 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
> 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