Of Pyramids and Igloos

A Brief Cultural Perspectiv e

by S . Ron Olive r
Department of Computer Scienc e
California Polytechnic State University
San Luis Obispo, C A

Some 30 to 50 centuries ago, for a period of history covering more than 2 0

centuries, inhabitants of the Nile river valley devoted impressive levels of effor t
to construct a number of burial crypts, generally known as pyramids. Little i s
known about how long it took to build a pyramid, but the larger ones, at least ,
must have taken many years or even decades . To the best of our knowledge thes e
edifices were almost strictly non-utilitarian, serving merely to fortify a few nobl e
men and women for their journeys and adventures in the after-life . In retrospect,
however, the pyramids played a much more important role for the posterity o f
those nobles . Because they were constructed so carefully, so sturdily, and becaus e
they entombed not only corpses but a wealth of cultural artifacts, a very
significant part of the society and culture that produced them has been preserve d
for us to study and understand .

Igloos constructed of hard-packed snow, by contrast, require relatively little effor t

to build, and may be erected in a matter of hours or at most a few days .
Contemporary mountaineers learn to construct small snow shelters, using simila r
methods, in a matter of minutes . Igloos and impromptu snow shelters are almos t
strictly utilitarian, serving little religious or aesthetic purpose . Moreover, the y
rarely last more than a few months . We know of them only because we know of ,
and interact with, the people who build them . Almost everything we know o f
those people has been learned by means independent of their igloos .

Some software projects are very much like pyramids : They require man-centurie s
of effort and calendar years, or even decades, to complete . Other softwar e
projects are more like igloos : one or at most a few software engineers ` produc e
them in a matter of months or weeks, or more rapidly . Every software enginee r
has, on several occasions, single-handedly produced some 'quick and dirty' piec e

' The term 'software engineer' is used loosely to be synonymous with 'programmer' or 'softwar e
developer', or whatever term may be used to describe one who writes or develops software .

ACM Ada Letters, Jul/Aug 1994 Page 36 Volume XIV, Number 4

 of code in a matter of minutes, or at most hours . Indeed, this development styl e
is culturally induced into every computer science student throughout the entir e
computer science curriculum .'

The Ada programming language is similar to a pyramid in many respects . Ada

was originally envisioned by the U . S . Department of Defense (DoD) to solv e
problems in developing large, complex defense systems . It was conceived as a
tool that would make it possible to more reliably build large software systems an d
complete them on schedule, where that schedule involves several years o f
development time, by hundreds of people . Moreover, the design, specification ,
and development of Ada has, by intent, involved thousands of scientists an d
engineers from all over the world . The effort has been ongoing for more tha n
fifteen years, and will likely continue for at least another decade . That is, Ada ,
the language, as well as the intended products to be built with Ada, all are mor e
like pyramids in scope and complexity, than like igloos .

Like pyramids, also, Ada is a very sturdy language . This results from a
combination of the thoroughness of the Language Reference Manual (LRM) an d
the requirement that Ada language processors pass a validation suite. Large ,
complex programs written in Ada may be readily, even trivially, ported amon g
environments as varied as : Meridian's Open Ada on a Personal Computer ; Alsy s
Ada on an IBM 3090 ; Verdix Ada on a Sequent Balance 8000 multiprocesso r
system . More importantly, for the first time in the history of programming, Ad a
really does present the opportunity to build sturdy 'pyramids' (large, complex
software systems that are reliable and portable) .

Other programming languages, such as Algol, Pascal, or C, are more like igloos
than pyramids . They were conceived and implemented by one or a few person(s) ,
and they are not very sturdy, nor are they adequate for building sturdy pyramids .
Consider C, for example . It has certainly withstood the test of time in that it ha s
become widely used in a large variety of environments . But it is not sturdy i n
ways a language should be sturdy . There is a reasonably well-defined ANS I
specification for C, but it is rarely enforced . Relatively small, simple C program s

2 To be sure, most computer science faculty recognize the need to expose students to large, comple x
projects, and most computer science programs provide at least one opportunity intended to expose the studen t
to projects much larger than the norm for programming assignments . But the predominant and earlies t
exposure to software development invariably pressures the student to individually develop small pieces o f
code, in a very short time . Furthermore, the very nature of the undergraduate experience (a few years devote d
to three or more parallel 'projects' (courses) at any given time, each of short duration, is such that the best -
conceived 'large' projects are quite small and simple by comparison with typical industrial experience .

ACM Ada Letters, Jul/Aug 1994 Page 37 Volume XIV, Number 4

 (especially those likely to be written by a student) will often fail to be easil y
portable among a variety of environments . Even moving C code from the AI X
operating system on an IBM PS/2 to AIX on an IBM 3090 can be painful .
Whereas C is an excellent medium for building igloos (quick and dirty programs )
it is entirely unsuited for building pyramids .'

But what of the future? C, especially C++, seems to be gaining in popularity, i n

spite of its deficiencies . Ada is being used more and more, but does not appea r
to be gaining in use at the rate some would have expected . Why? I s
contemporary society rejecting the option of building sturdy software products i n
favor of quick and dirty ones? There are, of course, no short and simple answer s
to these questions . Several factors must be considered .

Until very recently cost and availability have been major factors . Whatever
deficiencies C has, the price has been right (very low or free), and it has bee n
implemented in every context imaginable . Although it has been widel y
implemented, there are relatively few vendors of Ada, and they have implemente d
Ada in relatively few environments, by comparison with C . Moreover, the cos t
to purchase Ada has been astronomically high . There have been other cos t
factors, too. The amount of disk space and memory required by the Ada compiler
is substantially greater than for C .

Ada prices are now declining. As this trend continues, and the amount o f
available disk space and memory continues to expand, these factors will soon b e
outweighed by the portability, reliability, readability, and other benefits of Ada .
Also, the GNAT project was specifically conceived to address the cost an d
availability issues . Will it work ?

Other less tangible factors will probably continue to make C more popular than
Ada for some time to come . Students are so clearly molded to be igloo builders ,

' While it is true that many pyramids have been built with C, they almost never meet minimal standard s
for sturdiness . Unix is the most notorious example . Unix has been around and evolving for some 20 years .
But it is still operationally unstable, and an engineering nightmare to maintain . It crashes periodically - fa r
too often for a system that has been around for two decades . It is also dangerously insecure, and concerted
efforts to overcome this deficiency have been thwarted by the complexity and mystery of Unix cod e
(complexity and mystery that would be extremely unlikely to obtain, were the system written in Ada) . At
the Computer Systems Laboratory (CSL) in the Department of Computer Science at Cal Poly no fewer tha n
five different Unix environments are supported . These systems are difficult enough to support, and differen t
enough from each other, that it is necessary to train student system administrators with a focus on one or, a t
most, two of them . The best system administrators are often unable to help with one of the systems that have
not been their focus . Worse, one or another of the systems are broken into, several times a year . Network
trespassing often results in loss of information, and always in unnecessary expenditure of precious resources .

ACM Ada Letters, Jul/Aug 1994 Page 38 Volume X/V, Number 4

 how can they be expected to become pyramid builders, or even to appreciate th e
benefits of pyramids over igloos? By the time they have built enough igloos t o
begin to desire to build pyramids they have likely done most of the building the y
are going to do in their professional lives . They are about to go off and do othe r
things like manage a younger group of igloo builders . What can be done to
change the mold? How can the traditional educational system be reoriented
toward a 'single focus' pyramid culture rather than the smorgasbord igloo cultur e
it presently reflects ?

Another issue has to do with common misperceptions about the Ada project itself .
Many people have complained about the failure of Ada to meet certain needs -
most notably in the area of distributed real time systems . Many have had bad
experiences with early Ada products . Some have concluded that Ada has failed ,
or is a dying language, because it has been around for 'so long', yet no one i s
using it . The fact is, by pyramid standards, Ada is still in a very early stage o f
development. Recall that the LRM was not completed until 1983 . Do D
embedded systems were not required to be implemented in Ada before July 1987 .
Given the ambitious nature of the LRM it would have been surprising, indeed, i f
a good, reliable implementation of Ada had been available by 1987 - especially
since developers had to rely primarily on igloo builders and igloo technology . At
the present time reasonably good implementations of Ada (1983) are available i n
many environments . When a large pyramid is being built it seems reasonable t o
claim things are going well if a stable foundation has been established after a mer e
decade of effort! Moreover, Ada 9X promises to alleviate many of th e
weaknesses of Ada 83 .

In fact, it must be understood that Ada (1983) is only a start of the pyramid . A
generous estimate is that it represents approximately one-third of the require d
number of tiers. Ada 9X will improve substantially on the grandeur of this
structure, but it could easily be another decade before good, reliable Ada 9X
implementations are widely available . Even then the pyramid will not b e
complete . A generous estimate is that 9X will add approximately another on e
third of the required number of tiers . Ada 9X cannot possibly complete the effort .
Pyramids just are not that easy to build !

In reality, the pyramid may never be complete . The list of 'required' feature s
keeps growing as the industry is fairly rapidly evolving new techniques an d
concepts for programming languages and environments . Object Oriented features ,
being incorporated in Ada 9X, are a case in point. When Ada (1983) was being
specified, Object Oriented methods had not become widely known or popular.
This is one way in which the analogy breaks down to some extent . Although

ACM Ada Letters, Jul/Aug 1994 Page 39 Volume XIV, Number 4

 there are interesting cases of Egyptian pyramids that were never complete d
because the Pharaoh kept changing his vision of what it should be, right up to th e
time he needed it, those cases tend to be the exception . It is not likely tha t
Egyptian cultural conceptions, or 'pyramid design' principles, evolved at a pace
comparable to the rate of change contemporary society has been experiencing wit h
computing technology . What new language features will be viewed as 'necessary' ,
by the year 9X?

Finally, the critical questions must be asked : Should this society be buildin g
pyramids at all? Do pyramids really offer substantial cultural benefits? Or ar e
they simply vestiges of the past, an inherited fixation on the after-life? Certainl y
one of the reasons igloos have worked so well is that, though short-lived an d
unsturdy, they tend to last and serve 'long enough' and 'well enough' . The rapi d
pace of technology change has forced the abandonment of old igloos in favor o f
new ones on a regular basis . Had the time and effort used to build those igloo s
been redirected to building pyramids, most of them would have become obsolet e
long before they became usable .

Ironically, it was just this phenomenon that motivated the DoD to initiate the Ad a
project. Too many software projects were coming in too late, over cost, an d
failing to meet requirements . In many cases hardware for which software system s
were designed was no longer supported by the time the software was done ,
exacerbating the problems . The DoD had to have a better, more reliable way to
build pyramids within budget and schedule . Or did they? Perhaps therein lies th e
problem : perhaps the DoD should have resolved to stop building pyramids an d
rely only on igloos !

Who could have predicted the rapid pace of technology change that made igloo s
a better bet than pyramids? Will that rate of change continue? Will it continu e
to be beneficial to discard software products, in favor of newer technology, ever y
few years? If so, igloos are the only hope . Some say the rate of change can' t
possibly continue . But 'some' have been saying something like that for the pas t
two decades, if not longer .

What, if anything, can or should be done? As previously noted, there are n o

short, simple answers to the questions raised here . It is just too quick and dirty
to assume that igloos will continue to be the best bet because they 'always hav e
been' . In reality, society needs both pyramids and igloos . A major problem i s
how to decide which technology best fits a given circumstance . Another majo r
problem, with current trends in U .S . DoD funding, is where to get the resources
to keep building the Ada pyramid to ensure there will be an adequate tool fo r

ACM Ada Letters, Jul/Aug 1994 Page 40 Volume XIV, Number 4

 building pyramids . The most serious problem is how to effect a cultural chang e
to be able to produce enough pyramid builders to fulfill the needs of society . This
will require, at the very least, substantial changes in the educational system .

The introductory Computer Science sequence is still patterned very much like i t
was thirty years ago : programming-in-the-small, rather than programming-in-the-
large . The author and a colleague presented a paper at SIGCSE '94 describing a
plan to aggressively reorient CS1 and CS2 toward programming-in-the-larg e
(Oliver and Dalbey, Proceedings of The 1994 SIGCSE Technical Symposium ,
ACM Press) . Although Software Engineering is now a component of virtuall y
every Computer Science curriculum, it is generally considered to be an uppe r
division or graduate course . In many cases students take Software Engineerin g
after taking a course in which they have developed a rather large comple x
software system in a group context . Software Engineering should be taken righ t
after the introductory sequence and before any course with a significantly larg e
software development project . A good pyramid builder, after adjusting to th e
climatic change, can readily become a very good igloo builder . The opposit e
transition does not appear to be so easy .

Government resources in support of Ada must be used much more effectively ,

especially during these times of significant budget reductions . Considerable effort
is being focused on Ada 9X, and for good reasons . But Ada 83 is not yet
completed . There are some stable Ada compilers, but there are also some tha t
behave much more like gigantic 'pyraloos' . When used for moderately larg e
applications they tend to cave in on the developers . Moreover, there are so fe w
vendors of Ada compilers the ususal forces of competition are not effectivel y
encouraging vendors to do a better job . Resources must be devoted to ensurin g
there are more vendors, and there is incentive to produce higher quality products .

The Ada Joint Program Office has shown a substantial revision in policies an d
orientation with the 9X project, compared with those during the early days of Ad a
83 . More consideration has been given for the way people actually develo p
concurrent and real time systems, for instance, leading to much more reasonabl e
support for embedded systems in particular . The GNAT project, already
referenced, represents another significant change in orientation . Perhaps most
important is the strong commitment to work with the academic community t o
ensure students are afforded good learning environments . The most successfull y
designed language will never really succeed if it does not become a part of th e
educational process that produces computing professionals . But additional polic y
changes should be seriously considered . At a minimum, the government shoul d
require that Ada compilers be written in Ada . Also, although there has been

ACM Ada Letters, Jul/Aug 1994 Page 41 Volume X/V, Number 4

 considerable work to improve the validation process, more is needed . There must
be a systematic way for users, having discovered unacceptible compiler behavior ,
to document these and have the validation suite updated, dynamically, throughou t
the life of Ada 9X . This method must include teeth that require an already -
validated compiler to undergo revalidation, under some circumstances . Admittedly
this latter issue will be very difficult to enforce fairly and without reducing furthe r
the number of vendors . But it is important for the validation process to be a
living process.

The community of professional Computer Scientists (SIGAda members, i n

particular) must reorient its focus, too . So many of us have been so focussed o n
the Ada pyramid, we have lost site of the purpose : to build application pyramids .
Consider recent Tri Ada proceedings, for instance . How useful are the papers
being presented at Tri Ada for the prospective application pyramid builder? T o
be sure some of the papers are quite useful, but there is a distinct preocuppation
with the Ada pyramid . Some have noted that attending Tri Ada is like attending
a convention of 'language lawyers' . Most prospective pyramid builders will no t
be attracted to studies in 'High Priesthood' . They just want to learn about building
application pyramids . Where are the myriad of papers that demonstration th e
methods and virtues of application pyramid building (vs Ada pyramid building) ?

But there sill remains the hardest question of all : Are pyramids even appropriate ?
Unlike the builders of pyramids along the Nile, we live in a time and place wher e
buildings must be utilitarian, and their cost must be justified by their utility . Why
is it that temporary shelters (igloos) are utilitarian? Because their builders ar e
nomads : they keep moving around, so that 'long enough' is perfectly acceptable .
For a variety of technological and economic reasons, contemporary users o f
software are essentially nomadic . In a relatively short time (every 2-3 years) the y
migrate to newer, more cost effective hardware, and adopt the latest 'fast food '
software . This is reality . How do pyramids fit into such a cultural context? Th e
only possible way is through a combination of portability and extensibility . Ada
9X has been carefully designed to be highly portable and highly extensible . But
will Ada 9X become real in time to be a player? Will there ever be Ada 9 X
compilers that have been as carefully engineered to implement the design? Wil l
it ever be possible to recoup the investment ?

In summary, significant academic reform, vendors that produce high qualit y

implementations of the Ada pyramid, and real world demonstrations that buildin g
pyramids is cost effective, are all essential to the success of the Ada experiment -
essential but not necessarily sufficient . Whether or not the Ada experimen t
succeeds will inevitably be determined by the sands of time .

ACM Ada Letters, Jul/Aug 1994 Page 42 Volume XIV, Number 4