SE Principles Silver Bullets

1. SE PrinciplesSilver Bullets CS 620/720 Software Engineering January 15, 2004

2. Poor Engineering leads to ad-hoc structure! The result of continuous building without any thought toward design. Result: Stairs leading to ceiling; Windows in the middle of room; Doors opening to wall; Non-intuitive floor plan!.

3. Poor Engineering Has Disastrous Consequences! Aerodynamic phenomena in suspension bridges were not adequately understood in the profession nor had they been addressed in this design. New research was necessary to understand and predict these forces. The remains, located on the bottom of the Sound, are a permanent record of man's capacity to build structures without fully understanding the implications of the design. http://www.nwrain.net/~newtsuit/recoveries/narrows/narrows.htm

4. Poor Engineering Has Disastrous Consequences!$7 Billion Fire Works – One Bug, One Crash On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded. The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift- off). This loss of information was due to specification and design errors in the software of the inertial reference system. The launcher started to disintegrate at about H0 + 39 seconds because of high aerodynamic loads due to an angle of attack of more than 20 degrees that led to separation of the boosters from the main stage, in turn triggering the self-destruct system of the launcher. This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine. These nozzle deflections were commanded by the On-Board Computer (OBC) software on the basis of data transmitted by the active Inertial Reference System (SRI 2). Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer of the SRI 2, which was interpreted as flight data. The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a failure due to a software exception. The OBC could not switch to the back-up SRI 1 because that unit had already ceased to function during the previous data cycle (72 milliseconds period) for the same reason as SRI 2. The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose. The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5. Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 and is not required for Ariane 5. The Operand Error occurred due to an unexpected high value of an internal alignment function result called BH, Horizontal Bias, related to the horizontal velocity sensed by the platform. This value is calculated as an indicator for alignment precision over time. The value of BH was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher horizontal velocity values. http://java.sun.com/people/jag/Ariane5.html http://www.around.com/ariane.html http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.htm l

5. Poor Engineering Has Disastrous Consequences! • Software Runaways: Lessons Learned from Massive Software Failures, Robert Glass • Denver Airport • Safeware: System Safety and Computers, Nancy Leveson • Therac-25 http://sunnyday.mit.edu/papers/therac.pdf • Risks to the Public, Peter Neumann • http://www.csl.sri.com/users/risko/risks.txt

6. Poor Engineering Has Disastrous Consequences! • Can you think of other examples….?

7. 1968: Birth of Software Engineering • 1968 NATO Convention on new field of Software Engineering • http://www.cs.ncl.ac.uk/old/people/brian.randell/home.formal/NATO/index.html • Virtual “Who’s Who” • Dijkstra, Naur, Perlis, Gries

8. First Software Reuse paper • Doug McIlroy

9. 1968 NATO SE • The conference must have been tiring….

10. No Silver Bullet : Essence and Accident in Software Engineering • IEEE Computer, April 1987 • Brooks was the 2000 Turing Award winner • Brooks Law • Mythical Man Month • UNC

11. Silver Bullets “But as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, either in technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. Not only are there no silver bullets in view, the very nature of software makes it unlikely there will be any.” Frederick Brooks, The Mythical Man Month No magical cure for software crisis…

12. In a nutshell “I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labour of representing it and testing the fidelity of the representation.”

13. SE: A Disciplined ApproachKill the Snake-Oil The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today.

14. Essence and accident All software construction involves • essential tasks — the fashioning of the complex conceptual structures that compose the abstract software entity [i.e., problem-space], and • accidental tasks — the representation of the abstract entities in programming languages and the mapping of these onto machine languages within space and time constraints. [Distinction originally due to Aristotle.]

15. Brooks’ thesis Good news! • We have made great headway in solving the accidental problems! Orders of magnitude improvements! Bad news! • Progress on essential problems will be much slower going. • “There is no royal road, but there is a road.”

16. “No Silver Bullet” – Fred Brooks • Like physical hardware limits, there are problems w/ SW that won’t be solved • Inherent difficulties of software production • complexity • conformity • changeability • invisibility

17. Complexity • Software is complex, even when done right. • Many components • Many kinds of interactions between components • Combinatorially many states, syntax must be just so or else. • 16 bit word in HW -> 216 states • Def-use of variables and state changes • Rich structure, interesting dependencies add to complexity. • Good interfaces, design can lessen externally-visible complexity • Accidental (as practised) issues add to complexity. • Efficient code is usually complicated code • Use of prefab abstractions; reuse and generic components mean complicated, stateful glue. • Complex code is harder to evolve, results in design drift and even more complexity.

18. Complexity • Complexity is an inherent property because there really are that many “moving parts”! • Hardware engineering is achieved by replication of relatively simple parts arranged just so to achieve a certain effect. • Software is NOT a physical system, it is entirely a design. • When two pieces of software perform the same task, we abstract them into one! • Thus the size of a [well designed] system measures not “mass” but complexity. • Complexity depends non-linearly on size • Results • difficult to understand whole product • errors in specification & code • hard to manage • how can you estimate without understanding? • maintenance is a nightmare

19. Conformity • Invariably, have to coerce nice [problem-space] abstractions to fit someone else’s prefab [solution-space] technology. • New kid on the block! (rules were already made) • Perceived as more flexible than hardware or humans • Result: bewildering diversity of requirements • Wrapping and unwrapping, data marshalling, etc. • Software has to be made to agree to common interfaces, protocols, standards, etc. • Interface with an existing system • e.g., plant built & asked to create SW to control • software must conform to the plant • Interface with a new system • misperception that SW is easier to conform • again, software will be forced to conform • Some translations/coercions can be automated and take care of themselves; it's the other ones that will cause our systems to break, often in very subtle ways.

20. Changeability “[…] the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product.” • We change software because we can! • Easy to update existing systems in the field (in theory). • E.g., Windows update web site • Can undo changes if desired (in theory). • Not like a car recall. • To be successful is to be changed! • Keep system flexible, marketable. • Try to anticipate and/or react to future unforeseen uses • Pressure to change • reality changes • useful software will encourage new requests • long lifetime (~15 yrs) vs. hardware (~4 yrs).

21. Invisibility “The reality of software is not inherently embedded in space.” • Software is invisible & unvisualizable • Different from physical laws and math theorems • no way to represent a complete product or overview • complete views (e.g., code) • incomprehensible • partial views • misleading • Makes it hard to communicate to • other software professionals • users & clients • Of course, we can use various techniques to help us visualize aspects of software (control flow, data dependencies, UML, etc.) • but that's NOT quite the same thing as, say, the blueprints of a building.

22. Attacks on accidental problems • HLLs • Frees us from byte-level thinking (accidental complexity). Takes us up to “generic problem space”. e.g., C, sizeof(int), register allocation vs. pure objects and garbage collection • What we need beyond this is common abstractions in problem space … • i.e., domain modelling: telephony, avionics, flight reservation • … and in solution space too • e.g., frameworks, libraries, components • HLLs and OOP [replace “Ada” by “Java”] • Good training/use will make for better systems. • When used well, bumps up the abstraction level • … but still begs the question • Won't “solve” the SE problem, but the abstraction aspects of OO live in problem space too. • This has been a HUGE win in attacking essential complexity.

23. Attacks on accidental problems • IDEs (SDEs) • This was novel then! Research systems can actually do lots more than VC++. • Even a smartly tweaked vim/emacs is a big step forward. • In the old days, correct and reasonably efficient compiling was a notable feat. It was hard to get Unix standalone tools to interoperate. • Current: Eclipse

24. What about these silver bullets? • AI and expert systems • Mostly not. • Sometimes they help, e.g., test oracles • Certainly, AI techniques are useful in many application domains, but not as a silver bullet to solve the SE problem. • WWW, faster processors, cheap memory have made some AI techniques quite useful, much more so now than then.

25. What about these silver bullets? • “Automatic programming” • i.e., state the parameters, turn the crank, hey presto a software system! • We can do this now in some cases, works quite well [it didn't work very well at the time of writing] • Some systems generate part of their source code: • Generative programming; model-based approaches • Will never work completely in the general case, but is certainly useful. • Really, all this does is bump up the abstraction level by one; • Great potential in domain-specific environments • Parsers: yacc, lex • MIC/GME

26. What about these silver bullets? • Graphical programming [e.g., UML, SDL, et al.] • Undeniably useful … as a tool … sometimes … • Always tempting to try, as certain aspects of software systems do seem inherently “topological”. • “A favourite topic for PhD dissertations in SE.” • In the general case, software is ethereal, unvisualizable (unlike hardware) with truly bizarre dependencies. • Surprisingly difficult to do well as most visual metaphors break down under scale (or bad design). • Have you ever looked at a complicated SDL state-machine diagram? A class diagram with lots of complex interdependencies? A use-case scenario diagram with lots of variation? • Improvement: Domain-specific visual languages

27. What about these silver bullets? • Formal program verification (Dijkstra: formal derivation) • Does program P implement specification S? • Undecidable in the general case, can be done by hand until scale overwhelms • In practice, has been done with some great successes, but only when investment seems to be worthwhile. • Tremendously expensive; requires expert logicians! • The hard part, as Brooks rightly points out, is making sure you have the right specification S! • Validation versus verification

28. What about these silver bullets? • Better tools and faster computers • Always good. Usually solution-space though. • Technological Peter Principle: • in a hierarchically structured administration, people tend to be promoted up to their "level of incompetence" • Cheap disks, fast modems? Napster!

29. Promising attacks on conceptual essence • Buy, don't build. • Old days [IBM 1960s]: specialists developed highly customized solutions Just For You. • Experience led to generic (or at least configurable) products; now we have “shrinkwrapped” software (one size fits all). • Advice to software developers: Learn how to build generic components or systems. This is hard, though. Modularization (next topic) plays a big role. • If customization is straightforward, this is a huge leap forward and an attack on the conceptual essence.

30. Promising attacks on conceptual essence • Rapid prototyping • Take requirements, build mock up, show to user, analyze feedback, repeat. • Early feedback means less chance for requirements errors (which are the most expensive), fast turnaround in problem space to narrow misunderstandings and educate customer. • Requirements are the essence of a software system. • Focusing on getting the requirements right is a direct attack on essential problems. • Relevance to XP?

31. Promising attacks on conceptual essence • Staged delivery [aka organic/incremental development, daily build] • Get a skeleton system up and running ASAP; flesh it out as you go. • Helps to get developers feeling like system is real. They add their updates as they finish them. They care about them not breaking. • Other extreme: big bang merging. Often lots of unpleasant surprises. • Microsoft (and many others) uses this approach; works well for them. • Need a culture that supports it. Lots of running around, not afraid of change, group buy-in, product-centred, etc.

32. Promising attacks on conceptual essence • Virtuoso designers (a.k.a. Cowboy code-slinger) • Find good people and keep them. • Pay them well, encourage them. • Above all, listen to them. • Ours is still a very young field … this reliance on magic and gurus is worrisome and anti-engineering. • However, “great software design” is mostly “pure” design (not engineering); it’s an act of creativity and innovation balanced against experience and good engineering. It’s impossible to teach, per se. • Note that great “artists” still require a grounding education in “classical techniques” and exposure to “best practices”.

33. Other Promising Technologies? • AOP? • MIC or MDA? • WWW? [1998] • Extreme programming? • design patterns, software architecture? • “The emergent evolution of hard interfaces” • e.g., imap, http, tcp/ip • Frameworks? • EJB, CORBA, COM, componentware? • scripting languages? • lawsuits? • your suggestions??

34. No Silver Bullet Refired • Brooks reflects on the “No Silver Bullet” paper, ten years later • Lots of people have argued that their methodology is the silver bullet • If so, they didn’t meet the deadline of 10 years! • Other people misunderstood what Brooks calls “obscure writing” • For instance, when he said “accidental”, he did not mean “occurring by chance”

35. Obtaining the Increase • Some people interpreted Brooks as saying that the essence could never be attacked • That’s not his point however; he said that no single technique could produce an order of magnitude increase by itself • He argued that several techniques in tandem could achieve that goal but that requires industry-wide enforcement and discipline

36. SE Principles - Parnas

37. Definition • Parnas starts this paper with a definition of SE as: • “multi-person construction of multi-version programs.” • Do you agree with this definition?

38. Excludes solo-programming… • The argument, in some way, makes sense: • Dividing the job • Specifying exact behavior • Team communication • …all of these things contribute to problems that need to be solved by applying SE principles.

39. But… • Is it not the case that developing a large application, even by yourself, necessitates the need for good SE? • Do we not need proper modularization when developing solo-progams? • If building a house relies on good construction and engineering skills, is it true that building a dog house (solo effort) does not?

40. Even building a dog house takes some engineering… From http://www.ttyler.8m.com/Dog%20House.htm Initially started as a "basic" dog house but soon turned into a masterpiece of quality workmanship.  Total time spent was 8 hours at a cost of $110 US.  Start with a piece of paper and a idea:  Design your dog house to the size and quantity of your dogs.  A perfectly built home is worthless if its to small to properly accommodate your dog.   Framing:  The framing process should be constructed with 2x4's or rip them in half for smaller homes.  A removable roof should be incorporated in assisting the future cleaning and maintenance. Wall Covering:  Should be tong & grove for a tight fit, no warping, and to cut down on cross drafts.  For large homes, plywood is a economical material that can be used.   Roof:  30 year home shingles cut down to the proper size.  As for this house, an oriental piece was constructed then topped of with a copper fence post top.  An additional hours work and $15 cost was needed Trim & Finishing Touches:  Trim can add a lot to the astidics of your dog house.  Trim can be bought  with may different variations or with some craftsmanshipcan can be made with the use of a router. Sanding & Paint:  Sink all nails below the surface and cover with wood filler.  Prepare surface for painting by sanding wood filler, rough spots, and blemishes.

41. More SE Principles • It seems that the problems identified as 4-6 are not peculiar to solo-programming • 4. How to write programs that are easily modifiable. Programs in which a change in one part does not require changes in many other places. • 5. How to write programs with useful subsets. Remove uneeded parts • E.g., Zen and CORBA footprint • 6. How to write programs that are easily extended.

42. Structure • “The connections between program parts are the assumptions that the parts make about each other.” • Precursor to “Design by Contract”; Pre/Post conditions • “the properties that it expects other parts to satisfy” • “the system properties that it is required to guarantee”

43. Changeability • Parnas writes that these two concerns help when we ask: • “What changes can be made to one part without involving change to other parts?” • Or, as Dijkstra has written elsewhere: • “... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.”

44. Two Techniques for Controlling Structure • Decomposition • Technique for dividing systems into modules • Well-structured program is one with minimal interconnections between its modules (low-coupling) • More to be said in later lectures • Precise Specification • “precisely describing the assumptions that the designers of one module are permitted to make about other modules” • More also to be said on this later • Some examples of why it is easier in other “engineering” endeavours…

45. Decomposition and Simple Specification The prong and receptacle parts of a Lego™ block have been unchanged since 1932 [Lego, 2002].

46. Simple Interface Specification Since around 1850, the standard dimensions for an “air cell” masonry brick in the United States has been 2.5 x 3.75 x 8 inches [Chrysler and Escobar, 2000].

47. For next lecture… • Read chapter 7 of Parnas • “On the criteria….” • Perhaps one of the top 5 most cited papers in all of software engineering • I will also lecture on some things that you do not have to read (e.g., cohesion and coupling) • Pop quiz some time in semester possible • i.e., quiz not on typical Thursday, but Tuesday

48. A lot of review &“On the Criteria…” (hopefully) CS 620/720 Software Engineering January 20, 2004

49. Basic Definitions of SE • Software engineering is a discipline whose aim is the production of fault-free software, delivered on time and within budget, which satisfies the users needs [Schach]

50. Generic Lifecycle Models