USC Center for Software & Systems Engineering
24 Oct, ‘06
“They” say that where you stand depends on where you
sit – well, I have been sitting at the National Academies
for over 10 years. So let me explain the perspective that
gives me:
1. Basics of the U.S. Academies:
a. Private 501-c(3), but chartered by
congress -- honorific and advisory.
1863 and all that.
b. Structure today: NAS, NAE, IOM,
NRC
2. Scale of the operation
a. Process: ensures authoritative,
unbiased, independent advice
b. Committees: the best there is, no
COI, balanced biases, serve probono
c. Peer reviewed
d. 1 report/business-day
e. ~700 studies in process,
>5,000 comm mbrs
3. We kick the government in the shins all
the time! They keep coming back!
Draft 6/27/2016
USC CSSE Workshop
p. 1
4. “Topics” span the spectrum – but
generally about the state of technology
needed to inform some public policy
issue.
Recent examples:
Hydrogen Economy
RAGS
Engr of 2020
Speed vs Stealth (note all on Intrnet)
OK, bottom line, after ten years at the nexus of
engineering and public policy
 I am totally technically incompetent
 I tend to look at things through a public policy filter
 So, the following remarks should be viewed with an
appropriate amount of skepticism.
That said, I want to applaud the merger of these two
centers … but also issue you a challenge!
To explain the both the applause and the challenge,
however, I need to pull several threads together first.
Thread 1: About engineering – as many of you know, I
am fond of a quote from Theodore von Karmen
contrasting science and engineering. He said:
Science is about understanding nature –
understanding what is.
Engineering is about designing what has never
been.
Understanding what is vs. creating what has never been.
Draft 6/27/2016
USC CSSE Workshop
p. 2
My favorite operational definition of what engineers do
is
design under constraint
Engineering is creating, designing, what has never
been, but we are constrained by concerns of
Functionality (of course),
Size, cost, weight, power consumption, heat
dissipation,
safety, reliability, environmental impact,
ergonomics,
manufacturability, maintainability -- a long list of
such “ilities”.
I could go on … the point is that there are a LOT of
constraints.
Thread 2: Scientists talk a lot about the “scientific
method” – that idealized notion of hypotheses tested by
repeatable experiments that have the possibility of
falsifying the hypotheses.
The reality is that standards and methods of proof are
quite different in different scientific fields,
Although loosely based on this idealized model, the
standards of proof are quite different in, for example, the
physical sciences, the life sciences and the social
sciences.
<? Tell the Newton’s Laws vs “animal model” story?>
Draft 6/27/2016
USC CSSE Workshop
p. 3
We engineers don’t talk as much about the “engineering
method”, but
1. I think we should
2. It will be the essence of my challenge to you
3. It will be, in part, about design b/c of thread 1.
To be sure, there has been some thinking and writing
about “design” – the classic texts by Eb Rechtin on
“Systems Architecting” come to mind for example.
But I am not sure that is all of the “engineering method”.
Nor am I sure that it will manifest itself identically in all
engineering fields.
Thread 3: For years we software engineers skulked
around under the scorn of “real engineers” because of
the “bugs” (errors) in the systems we build.
“Real engineers”, we were told, knew how to build
correct, safe, and reliable systems – and we lesser
software beings ought to adopt their methods.
Well, I think we now understand why software is more
bug prone – principal among the reasons are:
1. Software is much more complex than traditional
engineered physical systems.
2. There are fewer constraints – sw has no mass,
dissipates no heat, etc. The net effect is that there
are many more design options.
3. The mathematics describing them lacks continuity.
Draft 6/27/2016
USC CSSE Workshop
p. 4
I want to elevate complexity to its own “thread”, so let
me skip it for now and talk about the other two.
First, constraints -- note that the laws of nature are the
designer’s friend in more than one way – one of those
ways is that they eliminate some design options, and
make others obviously undesirable.
Thus nature reduces the size of the “design space” of
options that the traditional engineer must consider.
Not so for software. While in principle the size and
speed of a program might preclude some design
options, in practice neither is a practical limitation.
Thus the “design space” is enormous.
Second, continuity -- the fact that physical systems are
described by continuous mathematics is what enables
thorough testing.
It is possible to test a physical system for one input
value and know that its behavior for small changes in
the input will be very similar.
Thus, if one tests a range of input values that are “close
enough”, you have exhaustively tested the system.
Not so for software.
If one of the 1010 bits of my laptop’s memory is changed,
a large, discontinuous change in behavior may occur.
Draft 6/27/2016
USC CSSE Workshop
p. 5
That, in turn means that an “exhaustive” test of a piece
of software must consider all possible “states” of
memory.
Just to get a feel for what that means, each bit in
memory can be in one of two states – so there are
2**1010 (roughly 10** 108) of them. That’s 10 raised to a
power that has a one followed by eight zeros.
Just for comparison, I believe there are about 10100,
atoms in the universe. Ten raised to a power of 1
followed by two zeros.
Thus the number of atoms in the universe is an
infinitesimal fraction of the number of states in my
laptop’s memory.
Bottom line, except for trivial programs, exhaustive
testing of software is impossible. The lack of
mathematical continuity is the culprit.
Thread 4: For a variety of reasons that I’ll outline
below, I believe that “traditional engineering” is
becoming more like software engineering.
The artifacts that traditional engineers produce are
becoming more like software.
Some of the reasons for that are:
1. First, and most obviously, because computers are
so flexible and cheap, they are being embedded in
everything.
Once one component of a system is software, the
Draft 6/27/2016
USC CSSE Workshop
p. 6
whole system acquires the problems of complexity,
reduced constraints, and lack of continuity.
2. The size of the design space is growing
independent of the use of sw – the use of “designer
materials”, for example.
3. New constraints – my father was a mechanical
engineer, and he did not worry about ergonomic
factors, or environmental impact, for example.
4. Finally, there is the intrinsic complexity of the
systems we have the nerve to engineer – I am
thinking of the Corps of Engineers “remediation” of
the Everglades, for example.
The Everglades are an incredibly complex, subtly
interdependent eco-system.
Alternatively, I have been trying to teach myself
some modern biology for the last couple of years
and have been struck by the immense complexity
of even simple procariotic cells – ie, bacteria.
The notion that traditional engineering practice will
anticipate all of the interactions in either of these
systems, and that there will be no unintended
adverse consequences of changing them, boggles
the mind.
So, for all these reasons, as I said before, I see
traditional engineering moving in the direction of
software engineering.
Draft 6/27/2016
USC CSSE Workshop
p. 7
That suggests that traditional engineers might look to
our experience producing software to see some of the
problems they will face looking ahead to ever more
complex, less constrained, and discontinuous systems.
Thread 5: Equally, software engineers might look ahead
to future systems to ponder the future of their own
discipline as well as that of “traditional engineering”.
In this regard I commend a recent report from the
Software Engineering Institute at Carnegie-Mellon
entitled Ultra Large Scale Systems.
What struck me about this report was not the “large
scale” aspect per se – we’ve been building systems just
a bit larger than we intellectual control of for a long time.
Rather, what struck me was the notion that these
systems would be crafted from components with many
“owners” -- and that those owners would not know who
used and depended on the component they were
responsible for.
We have talked about “systems of systems” for a long
time, but I, at least, had not contemplated the
implications of evolution of the component systems
ignorant of the dependencies their “users” have on
them.
And, what about “transitive properties” – properties that
my system has only because of a property that another
system that I use, but do not have control over, has.
Every design methodology I know of starts with an
analysis of the “requirements”.
Draft 6/27/2016
USC CSSE Workshop
p. 8
The SEI report suggests we may not be able to know
them in these ultra large scale systems.
Thus I may make an “improvement” or “correct an
error” in the system I control and yet “mess up” a
system that uses mine because it depends on a property
that I did not consider important – or perhaps that I was
not even aware of.
Or maybe you “fix” your system, which I use, and from
my perspective mine continues to work “correctly” – but
unbeknownst to me, one of my users depends on a
property that my system inherited from yours, and it
now fails.
One response to this situation, the “traditional” CS
response, is that
1. Every system should publish the properties that it
guaranties to provide, and
2. A user of that system should depend only on those
published properties
Unfortunately there is a healthy lack of realism in this
view.
Thread 6: I said earlier that I wanted to raise
“complexity” to its own thread – and that’s what I want
to do now.
An observation and a question:
Draft 6/27/2016
USC CSSE Workshop
p. 9
1. As we know, any sufficiently complex system will
have “emergent properties” – that is, behaviors that
were not predict baseded on the behaviors of its
components and their interconnection.
One can indefinitely debate whether more careful
analysis might have predicted these emergent
properties – but it is a fruitless debate. Emergent
properties happen!
In real systems they can be first order effects.
With a perfect knowledge of quantum mechanics,
and as much analysis time as you like, you won’t
predict the personality of Bill Wulf – it’s an
emergent property.
2. The usual mechanisms we have used for
controlling intellectual complexity are abstraction
and modularization.
But what happens when the modules are
themselves “ultra large” and their abstraction
ignores their very real emergent properties?
Indeed, what if those emergent properties are
among the first order behaviors of the modules?
Is it possible that modularization and abstraction as
we have used them are tools for “moderately large”
systems, but not ultra large ones?
The Challenge to CSSE: Maybe it is time to take a
serious look at the “engineering method” and rethink it
Draft 6/27/2016
USC CSSE Workshop
p. 10
in the context of what the SEI called Ultra Large Scale
Systems.
Maybe the answer will be the traditional one.
But maybe not.
Don’t be mislead by the “in principle” ability to control
dependencies in software.
Think again about the Corp of Engineers “remediation”
of the Everglades.
It seems to me unassailable to me that some repair of
our previous damage to the Everglades’ environment is
needed.
But equally, it seems unlikely to me that we can
completely understand all of the dependencies of every
part of that eco-system on every other part.
What “engineering method” would let us proceed,
knowing that:
 Any action we take might have unintended
consequences.
 But not acting also has consequences.
It strikes me that the merger of software and systems
engineering centers creates just the right place to take
on the critical question of the “engineering method” for
the next generation of even more complex systems.
Thank you.
Draft 6/27/2016
USC CSSE Workshop
p. 11