CSE503: Software Engineering
Lecture 2  (March 29, 2000)

David Notkin

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?