Today’s plan:
v My “top 10” observations about SE, as a way to reinforce
my points of view from the first lecture and to point out some dimensions in
which we’ve evaluate ideas over the quarter.
v A very brief overview of SE
Notkin’s Top 10 Observations
v About software engineering
v With apologies and appreciation to many
unnamed souls
1) We make a huge mistake by assuming
similarity among software systems
a) Ex: Does (and should) the reliability of a
nuclear power plant shutdown system tell us much about the reliability of an
educational game program?
b) Ex: Does (and should) the design of a
sorting algorithm tell us much about the design of an event-based GUI?
c) So, assume differences until proven otherwise
2) Intellectual tools still dominate
mechanical tools in importance
a) How you think is more important than the
notations, tools, etc. that you use
i) Ex: Information hiding is a key design
principle
(1) Interface mechanisms can enforce
information hiding decisions but cannot help one make the decisions
ii) Ex: The notion of design patterns is more
important than languages that let you encode them
3) Analogies to other engineering disciplines
are attractive but generally fall apart quickly
a) One key reason is because of the incredible
rate of change in hardware and software technology
b) Another is that software seems to be
constrained by few physical laws
c) But I’ll make them anyway, I’m sure (and
you will, too)
d) This is a variation on #1
4) It is often too easy to estimate the benefits
of a “better” approach to engineering software without assessing its costs
a) “If only everyone only built software my
way, it'd be great” is a common misrepresentation
i) Ex: The formal methods community is just
starting to understand this
b) But at the same time, estimating the costs
and the benefits is extremely hard, leaving us without a good way to figure out
what to do
5) The properties that programming languages
can ensure are distant from the properties we require software systems to have
a) Programming languages can help a lot, but
they can't solve the "software engineering" problem
i) Ex: Contravariant type checking (such as in
ML) has significant benefits, but regardless, it doesn’t eliminate all errors
in ML programs
ii) And covariant typing, with its flaws, may
be useful in some situations
6) The total software lifecycle cost will
always be 100%
a) Software development and maintenance will
always cost too much
b) Software managers will always bitch and
moan
c) Software engineering researchers will
always have jobs
7) Software engineering draws on mathematics,
cognitive psychology, management, etc., but it is engineering and not mathematics, nor cognitive psychology, nor
management (nor etc.)
a) If somebody is talking about software
without ever mentioning “software”, run away
8) Tradeoffs are at the heart of software
engineering, but we're not very good at it
a) Getting something for nothing is great, but
it isn't usually possible
b) We almost always choose in favor of hard
criteria (e.g., performance) over soft criteria (e.g., extensibility)
c) This makes sense, both practically and
theoretically
d) Brooks’ Golden Rule doesn’t really work
e) But the situation leaves us up a creek to a
large degree
9) It's always good to (re-)read anything
written by Brooks, Jackson, and Parnas
a) Don’t fall into Mark Twain’s trap: “A classic is something everyone wants to
have read, but nobody wants to read.”
10) Software engineering researchers should
have a bit of the practitioner in them, and software engineering practitioners
should have a bit of the researcher in them
A very basic overview of
software engineering
v Software is critical to society
v Economically important
v Essential for running more enterprises
v Key part of most complex systems
v Essential for designing many engineering
products
v Sample code sizes (partly due to Jon Jacky)
Bar
code scanners 10-50KLOC
4-speed transmissions 20KLOC
GNU Emacs 120KLOC
ATC ground system 130KLOC
GCC 280KLOC
Teller machine 600KLOC
Call router 2.1MLOC
B-2 Stealth bomber 3.5MLOC
Seawolf submarine combat 3.6MLOC
Space shuttle 26MLOC+1MLOC/flight
NT5.0 60MLOC
v At 50 lines per page, double sided, 500
pages/ream (2 inches), a printed version of NT5.0 would be about 200’ tall
Ø That’s about 33 Notkin’s high or about
triple the height of the Suzzallo graduate reading room
v Dominant discipline (Stu Feldman, through
107)
Ø As the size of the software system grows,
the key discipline changes
Code Size Discipline
103 Mathematics
104 Science
105 Engineering
106 Social Science
107 Politics
108 ??
v Delivered source lines per person
Ø Common estimates are that a person can
deliver about 1000 source lines per year
§
Including
documentation, scaffolding, etc.
Ø Obviously, most complex systems require
many people to build
Ø Even an order of magnitude increase doesn’t
eliminate the need for coordination
v Inherent & accidental complexity
Ø Brooks distinguishes these kinds of
software complexity
§
We cannot
hope to reduce the inherent complexity
§
We can hope
to reduce the accidental complexity
Ø It’s not always easy to distinguish between
these kinds of complexity
v “The Software Crisis”
Ø We’ve been in the midst of a “software
crisis” ever since the 1968 NATO meeting
Ø crisis -- (1) an unstable situation of extreme
danger or difficulty; (2) a crucial stage or turning point in the course of
something [WordNet]
Ø We cannot produce or maintain high-quality
software at reasonable price and on schedule
§
Gibb’s Scientific American article
§
“Software
systems are like cathedrals; first we build them and they we pray” —Redwine
Ø My view—“mostly hogwash”
§
Given the
context, we do pretty well
§
We surely
can, should and must improve
§
Some
so-called software “failures” are not
· They are often management errors (Ariane,
Denver airport, etc.)
· Read comp.risks (far better than
comp.software-eng)
§
In some
areas, we may indeed have a looming crisis
· Safety-critical real-time embedded systems
· Y2K?
Ø Some “crisis” issues
§
Relative cost
of hardware/software
§
Low
productivity
§
“Wrong”
products
§
Poor quality
· Importance depends on the domain
§
Constant
maintenance
· “If it doesn’t change, it becomes useless”
§
Technology
transfer is slow
v SE <> PL
v Why is SE hard?
Ø There is no single reason software
engineering is hard—it’s a “wicked problem”
Ø Lack of well-understood representations of
software [Brooks] makes customer and engineer interactions hard
Ø Relatively young field
Ø Software intangibility is deceptive
§
Law XXIII,
Norman Augustine [Wulf]
“Software is like entropy. It is
difficult to grasp, weighs nothing, and obeys the second law of thermodynamics;
i.e., it always increases.”
v Is it engineering?