Chapter 4: Aristocracy, Democracy and System Design


This great church is an incomparable work of art. There is neither aridity nor confusion in the tenets it sets forth. . , ,

It 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



Conceptual Integrity

The typical situation for a cathedral building is being made during several generations by several builders, where each period shows the ideas and “improvements” of those in command at that moment.

The Reims Cathedral is the counterexample: the building integrity was achieved by the self-abnegation of eight generations of builders whom sacrificed some of his ideas in benefit for the construction pure design.

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.

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.


Achieving Conceptual Integrity

The purpose of a programming system is to make a computer easy to use.

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, which did not happen in software development old days. Because ease of use is the purpose, the ratio of function- conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design.

For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness.

It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice. Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect 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.

  • Division of labour between architecture and implementation.
  • The Surgical Team structuration

The separation of architectural effort from implementation is a very powerful way of getting conceptual integrity on very large projects. Complete and detailed specification of the user interface.  (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 has 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.

“Where architecture tells what happens, implementation tells how it is made to happen.”

In regard to the deeply emotional question of aristocracy versus democracy:

  • Are not the architects a new aristocracy, an intellectual elite, set up to tell the poor dumb implementers what to do?
    • 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.
  • 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?
    • Not only the architects will have good architectural ideas. Often the fresh concept does come from an implementer or from a user. However, 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 system and starts again on an integrated system with different basic concepts.

The external provision of an architecture 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 implementing group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift.


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”

When it is proposed that a small architecture team in fact write all the external specifications for a computer or a programming 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.

In the computer systems business the pace is quicker than in construction (where design comes first, building comes after), and one wants to compress the schedule as much as possible. How much can specification and building be overlapped?

The total creative effort involves three distinct phases: architecture, implementation, and realization, which can in fact begun in parallel and proceed simultaneously. Meanwhile, on the realization level there is much to be done also. Programming has a technology, too. Much work must be done on subroutine conventions, supervisory 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 labour 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 takes less time to test. In effect, a widespread horizontal division of labour has been sharply reduced by a vertical division of labour, and the result is radically simplified communications and improved conceptual integrity.

Chapter 1: The Tar Pit

A ship on the beach is a lighthouse to the sea.

DUTCH PROVERB

Over the years, all kind of animals have sunk in tar pits despite their efforts to scape.

Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with running systems—few have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficulty—any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem, and it is hard to discern the nature of it. But we must try to understand it if we are to solve it.


Programming System Products

Obsession with transition from garage programming to real programming system product

We start with a program, THAT is the thing commonly produced in garages, and what is used by the individual programmer for doing productivity estimations

There are two ways a program can be converted into a more useful, but more costly, object:

PROGRAM – PROGRAMMING PRODUCT

  • A programming product can be run, tested, repaired, and extended by anybody. It is usable in many operating environments, for many sets of data.
  • To become a generally usable programming product, must be written in a generalized fashion.
  • The range and form of inputs must be generalized as much as the basic algorithm will reasonably allow.
  • Then the program must be thoroughly tested, so that it can be depended upon. (A substantial bank of test cases, exploring the input range and probing its boundaries, must be prepared, run, and recorded)
  • Finally, promotion of a program to a programming product requires its thorough documentation, so that anyone may use it, fix it, and extend it.
  • I estimate that a programming product costs at least three times as much as a debugged program with the same function.

PROGRAM – PROGRAMMING SYSTEM

  • A programming system is a collection of interacting programs, coordinated in function and disciplined in format (the assemblage constitutes an entire facility for large tasks.)
  • To become a programming system component, a program must be written so that every input and output conforms in syntax and semantics with precisely defined interfaces.
  • The program must also be designed so that it uses only a prescribed budget of resources—memory space, input-output devices, computer time.
  • Finally, the program must be tested with other system components, in all expected combinations. This testing must be extensive, for the number of cases grows combinatorially. It is time-consuming, for subtle bugs arise from unexpected interactions of debugged components.
  • A programming system component costs at least three times as much as a stand-alone program of the same function.

PROGRAMMING SYSTEM / PRODUCT – PROGRAMMING SYSTEM PRODUCT 

  • This differs from the simple program in all of the above ways.
  • It costs nine times as much. But it is the truly useful object, the intended product of most system programming efforts.


programming-system-products


The Joys of the Craft

Why is programming fun? What delights may its practitioner expect as his reward?

  • The sheer joy of making things.
  • The pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful.
  • The fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning.
  • The joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
  • The delight of working in such a tractable medium. Almost pure thought-stuff. Building castles in the air, from air, creating by exertion of the imagination.

Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.


The Woes of the Craft

  • Not all is delight, however, and knowing the inherent woes makes it easier to bear them when they appear.
  • One must perform perfectly. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is the most difficult part of learning to program.
  • Other people set one’s objectives, provide one’s resources, and furnish one’s information. One rarely controls the circumstances of his work, or even its goal. In management terms, one’s authority is not sufficient for his responsibility.
  • The dependence upon others has a particular case that is especially painful for the system programmer. He depends upon other people’s programs (often maldesigned, poorly implemented, incompletely delivered (no source code or test cases), and poorly documented). Forcing to  spend hours studying and fixing things that in an ideal world would be complete, available, and usable.
  • Designing grand concepts is fun; finding nitty little bugs is just work. With any creative activity come The Woes of the Craft dreary hours of tedious, painstaking labour.
  • Debugging has a linear convergence, so testing drags on and on, the last difficult bugs taking more time to find than the first.
  • The product over which one has laboured so long appears to be obsolete upon (or before) completion. The technological base on which one builds is always advancing. As soon as one freezes a design, it becomes obsolete in terms of its concepts. But implementation of real products demands phasing and quantizing. The obsolescence of an implementation must be measured against other existing implementations, not against unrealized concepts.

The challenge and the mission are to find real solutions to
real problems on actual schedules with available resources.


This then is programming, both a tar pit in which many efforts have floundered and a creative activity with joys and woes all its own. For many, the joys far outweigh the woes, and for them the remainder of this book will attempt to lay some boardwalks across the tar.