1. Informatics 121 Software Design I
Lecture 4
Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

2. Discussion There will be discussion this Friday
Please join your designated discussion
Note classroom: SE2 1304
Part I of design studio due; part II comes out
It is the responsibility of missing team mates to contact the team, not the other way around

3. Today’s lecture
Design failures
Design is difficult
Design studio 1

4. Design failures

5. Design failures

6. Design failures
Zune
(2006)

7. Design failures
(1988)

8. Design failures
(1988)

9. Design failures
(1988)

10. Design failures
(1988)

11. Design failures
(1979)

12. Design failures
(1984)

13. Design failures

14. Software design software designer software compiler runnable program
other stakeholders
users
experiences

15. Design failures Air-Traffic Control System in LA Airport
Incident Date: 9/14/2004 Ironic Factor: ***** (IEEE Spectrum) -- It was an air traffic controller's worst nightmare. Without warning, on Tuesday, 14 September, at about 5 p.m. Pacific daylight time, air traffic controllers lost voice contact with 400 airplanes they were tracking over the southwestern United States. Planes started to head toward one another, something that occurs routinely under careful control of the air traffic controllers, who keep airplanes safely apart. But now the controllers had no way to redirect the planes' courses.
...
The controllers lost contact with the planes when the main voice communications system shut down unexpectedly. To make matters worse, a backup system that was supposed to take over in such an event crashed within a minute after it was turned on. The outage disrupted about 800 flights across the country.
Inside the control system unit is a countdown timer that ticks off time in milliseconds. The VCSU uses the timer as a pulse to send out periodic queries to the VSCS. It starts out at the highest possible number that the system's server and its software can handle—232. It's a number just over 4 billion milliseconds. When the counter reaches zero, the system runs out of ticks and can no longer time itself. So it shuts down.
Counting down from 232 to zero in milliseconds takes just under 50 days. The FAA procedure of having a technician reboot the VSCS every 30 days resets the timer to 232 almost three weeks before it runs out of digits.

16. Design failures NASA Mars Climate Orbiter
Incident Date: 9/23/1999 Price Tag: $125 million Ironic Factor: **** WASHINGTON (AP) -- For nine months, the Mars Climate Orbiter was speeding through space and speaking to NASA in metric. But the engineers on the ground were replying in non-metric English. It was a mathematical mismatch that was not caught until after the $125-million spacecraft, a key part of NASA's Mars exploration program, was sent crashing too low and too fast into the Martian atmosphere. The craft has not been heard from since.
...
Noel Henners of Lockheed Martin Astronautics, the prime contractor for the Mars craft, said at a news conference it was up to his company's engineers to assure the metric systems used in one computer program were compatible with the English system used in another program. The simple conversion check was not done, he said.

17. Design failures Ariane 5 Explosion
Incident Date: 9/1997 Price Tag: $500 million Ironic Factor: **** (By James Gleick) It took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the commercial space business. All it took to explode that rocket less than a minute into its maiden voyage last June, scattering fiery rubble across the mangrove swamps of French Guiana, was a small computer program trying to stuff a 64-bit number into a 16-bit space This shutdown occurred 36.7 seconds after launch, when the guidance system's own computer tried to convert one piece of data -- the sideways velocity of the rocket -- from a 64-bit format to a 16-bit format. The number was too big, and an overflow error resulted. When the guidance system shut down, it passed control to an identical, redundant unit, which was there to provide backup in case of just such a failure. But the second unit had failed in the identical manner a few milliseconds before. And why not? It was running the same software.

18. Design failures

19. Design failures

20. Design failures

21. Design failures

22. A caveat: not all design failures are bad

23. A caveat: not all design failures are bad
But we generally do not have this luxury!

24. Design failures designer plan maker change in the world
other stakeholders
audience
experiences

25. Design failures feasibility desirability designer plan maker
change in the world
other stakeholders
audience
experiences
desirability

26. Design failures application design interaction design
what is it to accomplish?
how does one interact with it?
application design
satisfactory experience
plan for realization
interaction design
change in the world
what is its conceptual core?
what are its implementation details?
architecture design
implementation design

27. Software design project
software design problem
software design solution
software design project

28. Two fundamental challenges
The nature of software
The nature of people

29. Nature of software (Brooks)
Complexity
software is among the most complex people-made artifacts
Conformity
software has no laws of nature that simplify its existence; rather, it lives in a world of designed artifacts to which it much conform
Changeability
software is subject to continuous pressure to change
Invisibility
because the reality of software is not embedded into space, it is inherently unvisualizable

30. Nature of people Diversity Indiscernibility Familiarity Volatility
people differ in how they experience the world
Indiscernibility
experiences are distinctly mental in nature, with tangible reactions and signs not always matching their actual experience
Familiarity
people tend to be risk averse, sticking to role, organizational, and societal norms and values
Volatility
with every new exposure, people reinterpret and modify their opinions and expectations

31. Software design is a wicked problem
The problem is not understood until after the formulation of a solution
Wicked problems have no stopping rule
Solutions to wicked problems are not right or wrong
Every wicked problem is essentially novel and unique
Every solution to a wicked problem is a “one shot operation”
Wicked problems have no given alternative solutions
Worse, software design is a ‘hard’ wicked problem

32. Seven difficulties every software designer faces
Prediction
Tradeoffs
Change
Bias
Longevity
Quality, cost, and effort
Source code as a design notation

33. Difficulty #1: predicting people’s experiences
Software design is a predictive activity that must anticipate the experiences of people
account for differing experiences
account for shifting experiences
Furthermore, when people share their vision for a future change in the world, they tend to be conservative
The difficulty lies in how to balance what people perceive they need and what they actually need

34. Difficulty #2: tradeoffs
Tradeoffs must be made continuously over the course of a design project
a design solution is judged relative to other possible solutions that could have been made
it is frequently impossible to quantify the relative virtues of each alternative
Furthermore, any given design solution inevitably satisfies certain stakeholders more than others
The difficulty lies in how to balance the decisions across the needs and experiences of the various stakeholders

35. Difficulty #3: change Change happens and must be accommodated
changing client demands
changing context of people, hardware, and software
changing understanding of the design problem
changing attitudes of the audience
Furthermore, the more complete a design solution already is, the more difficult it will be to change it
The difficulty lies in how to balance accommodating change with making sufficient progress on the design solution

36. Difficulty #4: bias
Bias exists within all stakeholders, and can be a positive or negative influence
audience
designer
client
others
Furthermore, bias is typically difficult to detect and address
The challenge lies in how to balance benefiting from positive bias while avoiding the effects of negative bias

37. Difficulty #5: longevity
Longevity is expected of most software design solutions
software does not wear out
software fulfills critical societal services
Furthermore, it very likely will need to accommodate new needs as well as deviations from present needs
The difficulty lies in how to balance addressing today’s design problem with accommodating future, unknown needs

38. Difficulty #6: quality, cost, and effort
Quality, cost, and effort are three constraining factors in design, not all of which can be optimized at the same time
cost constraints typically set by other stakeholders
cost constraints typically set before the design project is truly understood
Furthermore, there is no stopping rule, since no optimal design solution exists
The difficulty lies in how to balance a design solution that is of good enough quality with expectations on cost and effort

39. Difficulty #7: source code as a design notation
Source code is a terrible design notation for expressing goals, constraints, assumptions, decisions, and ideas
Furthermore, other software design notations typically do not map easily to source code
while they certainly help make progress, much manual effort remains in transforming findings stemming from the use of these notations to the source code
The difficulty lies in how to balance use of other design notations with the need to ultimately express the design solution in source code