1November 17, 2008 Lecture 35 1CS 390 – Lecture 35No Silver Bullet Frederick P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, Vol. 20, No. 4 (April 1987). Originally an invited paper for IFIP ’86 Conference and published in its proceedings. Reprinted in Brooks’ The Mythical Man-Month: Essays on Software Engineering, 20thAnniversary Edition, Addision-Wesley, 1995.November 17, 2008 Lecture 35 2Fred Brooks Project manager of IBM OS/360 1999 ACM Turing Award winner Founder (1964), former chair (20 years) of UNC-Chapel Hill Computer Science Department Currently, Kenan Professor of Computer Science at UNC-CHNovember 17, 2008 Lecture 35 3The Software Werewolf Software is like a werewolf – it looks normal until the moon comes out and it turns into a monster Missed deadlines Blown budgets Buggy software Everyone wants a silver bullet to kill the monsterNovember 17, 2008 Lecture 35 4There Is No Silver Bullet!“… no single software engineering development will produce an order of magnitude improvement in programming productivity within ten years…”November 17, 2008 Lecture 35 5Essential vs. Accidental Difficulties Following Aristotle, difficulties are either essential or accidental Essential: constituting or being part of the essence of something; inherent Accidental: Of or relating to a property, factor, or attribute that is not essential Note: This does not mean “by chance”November 17, 2008 Lecture 35 6Essential vs. Accidental Difficulties (2) Applied to software development, are difficulties: Essential – a fundamental quality of software development, OR Accidental – a problem of today’s software production methods2November 17, 2008 Lecture 35 7Past Breakthroughs Solve Accidental Difficulties High-level languages: eliminates much of accidental complexity by matching the level of the abstract program Time-sharing systems: preserves immediacy of code to its result Integrated development environments: allows programs to work together as conceptualized Libraries, file formats, pipes & filtersNovember 17, 2008 Lecture 35 8Analysis of Difficulties To get 10x improvement Accidental difficulties would have to be 9/10 of the overall problem Tools and techniques would have to reduce these difficulties to 0 Brooks’ conclusion First is not true (probably much less) Second is highly unlikely to happenNovember 17, 2008 Lecture 35 9Concept vs. Representation“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.”November 17, 2008 Lecture 35 10Essence of Software What makes writing software hard? Complexity Conformity Changeability InvisibilityNovember 17, 2008 Lecture 35 11Complexity No two parts are alike Huge numbers of states “…orders of magnitude more states than computers do…” Module interactions scale nonlinearly with size Cannot know the whole domain, process, or systemNovember 17, 2008 Lecture 35 12Complexity (2) Cannot abstract away the complexity because it is essential to the operation of the program Physics models work because the complex details are not concerned with the essence of the domain Complexity comes from the tight interrelationships between heterogeneous artifacts Specifications, documentation, code, test cases, etc.3November 17, 2008 Lecture 35 13Consequences of Complexity Communication overhead: cost overruns, schedule delays, personnel turnover Large number of states: unreliability Complex function: poor usability Complex structure: poor maintainability, security risksNovember 17, 2008 Lecture 35 14Conformity Software must conform to arbitrary limitations imposed by humans (e.g. business process rules) Software arrives late in system design Software viewed as most changeable It is hard to plan for arbitrary changes that will occur late in developmentNovember 17, 2008 Lecture 35 15Changeability Software is easier to change than hardware Asked to change during development Asked to change after deployment (post delivery maintenance); rare for manufactured things People underestimate the difficulties of changeNovember 17, 2008 Lecture 35 16Invisibility Code is invisible and unvisualizable Structure is extremely complex Structure is hidden There is only the external input/output viewNovember 17, 2008 Lecture 35 17Discussion Are Brooks’ claims true for the last 20 years? Next 50 years? Are the characteristics given really uniqueto software? Are there other essential properties? Have there been other accidental difficulties solved? Has there been significant progress since 1987?November 17, 2008 Lecture 35 18No “Silver Bullet” in 1987-1997 Languages like Ada: Remaining benefit small OOP: Good, but essential complexity remains AI: Not generally applicable; expert systems need an expert Automatic programming: Not generally applicable Graphical programming: Unvisualizable Program verification: Specification is still hard Environments & tools: Remaining benefit small Workstations: Faster compiles, but that is all4November 17, 2008 Lecture 35 19Is There Any Hope? Compare to medicine Throw out simple, fast fixes for demon-possession, four humours Apply persistent effort to slowly eradicate disease Compare to chemistry Throw out alchemy Spend years to understand atoms, then learn to synthesize goldNovember 17, 2008 Lecture 35 20Yes! There Is Hope “A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road.”November 17, 2008 Lecture 35 21Things to Try Reuse: “buy, don’t build” Requirements refinement and rapid prototyping Incremental development: “grow, don’t build” Better SE training: identification and nurturing of great designersNovember 17, 2008 Lecture 35 22“ ‘No Silver Bullet’ Refired” Brooks’ The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition also contained new chapter “ ‘No Silver Bullet’ Refired.”November 17, 2008 Lecture 35 23Reflections on “No Silver Bullet” Lots of controversy and rebuttals in 1987 But no