Lecture 26: No Silver BulletKenneth M. AndersonFoundations of Software EngineeringCSCI 5828 - Spring Semester, 2000April 19, 2000 ' Kenn eth M. Anderson, 2000 2Today’s Lecture• Discuss the No Silver Bullet paper• Brook’s reflections on it after nine yearsApril 19, 2000 ' Kenn eth M. Anderson, 2000 3No Silver Bullet“There is no single development, in eithertechnology or management technique,which by itself promises even one order-of-magnitude improvement within a decade inproductivity, in reliability, in simplicity.”-- Fred Brooks, 1986i.e. There is no magical cure for the “software crisis”April 19, 2000 ' Kenn eth M. Anderson, 2000 4Why? Essence and Accidents• Brooks divides the problems facingsoftware engineering into two categories– essence• difficulties inherent in the nature of software– accidents• difficulties related to the production of software• Brooks argues that most techniques attackthe accidents of software engineeringApril 19, 2000 ' Kenn eth M. Anderson, 2000 5An Order of Magnitude• In order to improve the developmentprocess by a factor of 10– the accidents of software engineering wouldhave to account for 9/10ths of the overall effort– tools would have to reduce accidents to zero• Brooks– doesn’t believe the former is true and– the latter is highly unlikely, even if it was trueApril 19, 2000 ' Kenn eth M. Anderson, 2000 6The Essence• Brooks divides the essence into foursubcategories– complexity– conformity– changeability– invisibility• Lets consider each in turnApril 19, 2000 ' Kenn eth M. Anderson, 2000 7Complexity• Software entities are amazingly complex– No two parts (above statements) are alike• Contrast with materials in other domains– They have a huge number of states• Brooks claims they have an order of magnitudemore states than computers (e.g. hardware) do– As the size of the system increases, its partsincrease exponentiallyApril 19, 2000 ' Kenn eth M. Anderson, 2000 8Complexity, continued• Problem– You can’t abstract away the complexity• Physics models work because they abstract awaycomplex details that are not concerned with theessence of the domain; with software the complexityis part of the essence!– The complexity comes from the tightinterrelationships between heterogeneousartifacts: specs, docs, code, test cases, etc.April 19, 2000 ' Kenn eth M. Anderson, 2000 9Complexity, continued• Problems resultingfrom complexity– difficult teamcommunication– product flaws– cost overruns– schedule delays– personnel turnover(loss of knowledge)– unenumerated states(lots of them)– lack of extensibility(complexity ofstructure)– unanticipated states(security loopholes)– project overview isdifficult (impedesconceptual integrity)April 19, 2000 ' Kenn eth M. Anderson, 2000 10Conformity• A significant portion of the complexityfacing software engineers is arbitrary– Consider a system designed to support aparticular business process– New VP arrives and changes the process– System must now conform to the (from ourperspective) arbritrary changes imposed by theVPApril 19, 2000 ' Kenn eth M. Anderson, 2000 11Conformity, continued• Other instances of conformity– Non-standard module or user interfaces• Arbitrary since each created by different people– not because a domain demanded a particular interface– Adapting to a pre-existing environment• May be difficult to change the environment• however if the environment changes, the softwaresystem is expected to adapt!• It is difficult to plan for arbitrary change!April 19, 2000 ' Kenn eth M. Anderson, 2000 12Changeability• Software is constantly asked to change– Other things are too, however• manufactured things are rarely changed– the changes appear in later models– automobiles are recalled infrequently– buildings are expensive to remodel• With software, the pressures are greater– software = functionality (plus its malleable)• functionality is what often needs to be changed!April 19, 2000 ' Kenn eth M. Anderson, 2000 13Invisibility• Software is invisible and unvisualizable– In contrast to things like blueprints• here geometry helps to identify problems and optimizations ofspace– Its hard to diagram software• We find that one diagram may consist of many overlappinggraphs rather than just one– flow of control, flow of data, patterns of dependency, etc.• This lack of visualization deprives the engineerfrom using the brain’s powerful visual skillsApril 19, 2000 ' Kenn eth M. Anderson, 2000 14What about X?• Brooks argues that past breakthroughs solveaccidental difficulties– High-level languages– Time-Sharing– Programming Environments• New hopefuls– Ada, OO Programming, AI, expert systems,“automatic” programming, etc.April 19, 2000 ' Kenn eth M. Anderson, 2000 15Promising Attacks on Essence• Buy vs. Build– Don’t develop software at all!• Rapid Prototyping– Brooks buys in• Incremental Development– grow, not build, software• Great designersApril 19, 2000 ' Kenn eth M. Anderson, 2000 16No Silver Bullet Refired• Brooks reflects on the “No Silver Bullet”paper, ten years later– Lots of people have argued that theremethodology 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 notmean “occurring by chance”April 19, 2000 ' Kenn eth M. Anderson, 2000 17The size of “accidental” effort• Some people misunderstood his point withthe “9/10ths” figure– Brooks doesn’t actually think that accidentaleffort is 9/10th of the job• its much smaller than that– As a result, reducing it to zero (which isprobably impossible) will not give you an orderof magnitude improvementApril 19, 2000 ' Kenn eth M. Anderson, 2000 18Obtaining the Increase• Some people interpreted Brooks as sayingthat the essence could never be attacked– That’s not his point however; he said that nosingle technique could produce an order ofmagnitude increase by itself• He argued that several techniques in tandemcould achieve that goal but that requiresindustry-wide enforcement and disciplineApril 19, 2000 ' Kenn eth M. Anderson, 2000 19Obtaining the Increase, continued• Brooks states– “We will surely make substantial progress overthe next 40 years; an order of magnitude over40 years is hardly
View Full Document
Unlocking...