Design Paradigms

1. Design Paradigms Petroski Intro – ch2 J. P. Gunderson UVA CS851 - Forensic Software Engineering

2. Approach • Not gonna read you the book • You should have already read it • Look at ramifications • Pull in some of his references • What does a bridge have in common with my software application, anyway? • Map his conclusions onto Software • Link back to Perrow’s Normal Accidents UVA CS851 - Forensic Software Engineering

3. Perspective • Building machines • Building machines to build machines • Three roles in building a machine • Designer • Engineer • Implementer • Two Aspects of Software • Software as a machine • Software development as a machine UVA CS851 - Forensic Software Engineering

4. Chapter 3 - Scale Matters • Galileo and the cube law • Vitruvius • The auger example • Diognetus and the crane UVA CS851 - Forensic Software Engineering

5. Cube Law Twice the length -> Four times the surface area -> Eight times the mass Human Femur Elephant Femur Hadrosaur Femur UVA CS851 - Forensic Software Engineering

6. Addressing Scale changes • Galileo pointed out that you can’t just scale up • Vitruvius adds that this also applies to force – double the size of the auger, quadruple the power needed to turn it • Diognetus’s crane shows that sometimes you have to make qualitative changes to overcome scale effects UVA CS851 - Forensic Software Engineering

7. Petroski has great cites • “And even in the late 20th century, failures of heavy steel sections( see, e.g., Fisher, 1984) and large missiles (e.g., Rosenthal, 1989) have been attributed to design errors in overlooking or underestimating the effects of size in scaling up successful designs.” • Rosenthal, 1988 – Trident 2 missiles • Take a fully functional model, and simply scale it up • What could go wrong? UVA CS851 - Forensic Software Engineering

8. The Good UVA CS851 - Forensic Software Engineering

9. Trident 2 • Designed by Lockheed to replace the Trident 1 • Let’s make it bigger • 44 feet long, twice as heavy as the Trident 1 • Subsequent analysis suggested that several problems occurred when the design was ‘scaled up’ • Original report NY Times 17Aug1989 • Risks (9)12 UVA CS851 - Forensic Software Engineering

10. The Bad UVA CS851 - Forensic Software Engineering

11. The Bad UVA CS851 - Forensic Software Engineering

12. The Bad UVA CS851 - Forensic Software Engineering

13. The Bad UVA CS851 - Forensic Software Engineering

14. The Bad UVA CS851 - Forensic Software Engineering

15. The Bad UVA CS851 - Forensic Software Engineering

16. The Bad UVA CS851 - Forensic Software Engineering

17. The Bad UVA CS851 - Forensic Software Engineering

18. The Bad • In the third test, ... instead of spinning end-over-end, (the missile) began flying on what at first seemed to be a normal trajectory ... "Then it appeared to be losing some thrust control and it self-destructed." Admiral Malley said he had not yet studied the full body of data from the test. But he said it appeared that the aft-end pressure had severed electrical connections... UVA CS851 - Forensic Software Engineering

19. The Kind of Pretty(in a sick way) UVA CS851 - Forensic Software Engineering

20. Scale Effects • The first time the missile was tested at sea, Admiral Malley said, the unexpectedly strong pounding from the water jet caused the (missile's rocket) nozzles to malfunction as soon as they fired above the water's surface. The missile began spinning in a spectacular cartwheel until it self destructed. ... • After reviewing the tests of the Trident 1, the Navy said, such jets were present, but had gone unnoticed because they had not affected the smaller missile's flight. UVA CS851 - Forensic Software Engineering

21. Is an algorithm scalable? Is this the same scale? When does it pay to switch algorithms? Is the software design process scalable? Functional decomposition Waterfall model Object oriented X Aspect oriented X Are design flaws being masked by ignorance factors? Scale Effects in Software UVA CS851 - Forensic Software Engineering

22. UVA CS851 - Forensic Software Engineering

23. Introduction • People learn by failing • Engineers are people • “Imagination and fear are among the best engineering tools for preventing tragedy.” • Spector and Gifford, Communications of the ACM, April 1986 • A Computer Science Perspective of Bridge Design UVA CS851 - Forensic Software Engineering

24. What do bridges have to do with my software? • Bridges (despite Petroski’s several books of failure analysis) are remarkably reliable • This is an interview that looks at the bridge design and implementation process. • Software development as a machine • There are some interesting contrasts between the way bridges are engineered and the way software is hacked together UVA CS851 - Forensic Software Engineering

25. Bridges start to finish • Preliminary Design Phase • Select the type and location • Main Design Phase • Produce all the design documents • Down to every bolt hole, and wire thickness • Construction • Schedule the construction • Design the construction process • Manage the construction UVA CS851 - Forensic Software Engineering

26. Preliminary Design • Done by a consulting engineering company • Starts with the requirements • Explore several alternative designs • Produces a document that details the options • Costs, locations, special construction • Maybe 100 pages • Make a recommendation • Approved by the stakeholders, before detail design starts (client, municipality, public) UVA CS851 - Forensic Software Engineering

27. Main Design • Resource analysis, scheduling • Model the bridge • Produce 50 – 200 drawings • Define components, interfaces, design in parallel • Few standard components • Specifications: • Special materials needed • Specific construction methods UVA CS851 - Forensic Software Engineering

28. Model the bridge • CAD, finite element • Possible prototype, if unusual requirements • Define major sub-components • Functions • Interfaces with other components • Model forces, static and dynamic loads • Interface with existing systems • Roads, waterways UVA CS851 - Forensic Software Engineering

29. Design • Small design team • Lead designer • Special teams (piers, foundations, deck) • Limited Parallelism • Verification: every calculation, part, material checked by a second engineer, final design re-checked by senior engineer. • If computer used, hand check hardcopy of inputs and outputs to remove transcription errors UVA CS851 - Forensic Software Engineering

30. Drawings • 50 to 200 drawings capture the details of the bridge design • Specifications capture any special needs • These are reviewed and approved by the stakeholders • While this captures most of the needed information for construction, the designers are on tap during construction phase. UVA CS851 - Forensic Software Engineering

31. Construction • Usually a different organization • Work with designers to make sure the right bridge is being built • Very different skill set from design, different training • Constant oversight • Inspections • Materials tests, etc. UVA CS851 - Forensic Software Engineering

32. Bridge building UVA CS851 - Forensic Software Engineering

33. Resources and Scheduling • 1.5 years to design a medium sized bridge • Construction 3 to 4 years • Design costs represent 6% of total cost • Resources: • Small bridge 1-5 person years • Medium bridge 10-30 person years • 6 to 20 person team • Large bridge up to 150 person years UVA CS851 - Forensic Software Engineering

34. Contrast with software • Bridges are designed and built using the waterfall model. • Could be 5 years from start to finish • Technology changes more slowly, model T’s still can cross bridges • Rate of usage increase quickly • Some new bridges are undersized before they are completed • But bridges don’t fall down as often as software crashes. UVA CS851 - Forensic Software Engineering

35. Normal Accidents • Interactions: • Can you modify part A without messing up part B • Coupling • Is it interruptible? • Is it a process or a series of steps • Bridge design: Where does it fit? UVA CS851 - Forensic Software Engineering

36. Bridges • Interactions • Naturally decomposes • But replacing a foundation would be hard • Coupling • Broken into interruptible phases • Each independent, input – process – output model UVA CS851 - Forensic Software Engineering

37. Where does Software Development fit? • Waterfall model is out of favor • Spiral models, eXtreme programming, etc. • Lack of separation between concept, design and construction • Often a lack of interface specifications, in spite of Parnas • When is the last time you had a complete specification (down to every variable type) before you started coding? • Who does your design review before it gets coded? • Who does the line by line code inspection before it ships • Tight coupling, high complexity UVA CS851 - Forensic Software Engineering

38. Normal Accidents • Supported by actual ‘accident’ rates? • What causes failures in the development of software? • Mars Polar Orbiter • Those who don’t learn from history… • How many buffer over-run patches in the last six months? UVA CS851 - Forensic Software Engineering