Today s Lecture Discuss the No Silver Bullet paper Brook s reflections on it after nine years Lecture 26 No Silver Bullet Kenneth M Anderson Foundations of Software Engineering CSCI 5828 Spring Semester 2000 April 19 2000 No Silver Bullet Kenn eth M Anderson 2000 Why Essence and Accidents There is no single development in either technology or management technique which by itself promises even one order ofmagnitude improvement within a decade in productivity in reliability in simplicity Fred Brooks 1986 Brooks divides the problems facing software engineering into two categories i e There is no magical cure for the software crisis Brooks argues that most techniques attack the accidents of software engineering April 19 2000 Kenn eth M Anderson 2000 2 essence difficulties inherent in the nature of software accidents difficulties related to the production of software 3 April 19 2000 Kenn eth M Anderson 2000 4 The Essence An Order of Magnitude In order to improve the development process by a factor of 10 Brooks divides the essence into four subcategories the accidents of software engineering would have 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 true April 19 2000 Kenn eth M Anderson 2000 complexity conformity changeability invisibility Lets consider each in turn 5 April 19 2000 Complexity Problem No two parts above statements are alike You can t abstract away the complexity Contrast with materials in other domains Physics models work because they abstract away complex details that are not concerned with the essence of the domain with software the complexity is part of the essence They have a huge number of states Brooks claims they have an order of magnitude more states than computers e g hardware do The complexity comes from the tight interrelationships between heterogeneous artifacts specs docs code test cases etc As the size of the system increases its parts increase exponentially Kenn eth M Anderson 2000 6 Complexity continued Software entities are amazingly complex April 19 2000 Kenn eth M Anderson 2000 7 April 19 2000 Kenn eth M Anderson 2000 8 Complexity continued Problems resulting from complexity difficult team communication product flaws cost overruns schedule delays personnel turnover loss of knowledge April 19 2000 Conformity unenumerated states lots of them lack of extensibility complexity of structure unanticipated states security loopholes project overview is difficult impedes conceptual integrity Kenn eth M Anderson 2000 A significant portion of the complexity facing software engineers is arbitrary Consider a system designed to support a particular business process New VP arrives and changes the process System must now conform to the from our perspective arbritrary changes imposed by the VP 9 April 19 2000 Conformity continued Software is constantly asked to change Non standard module or user interfaces Other things are too however Arbitrary since each created by different people manufactured things are rarely changed not because a domain demanded a particular interface the changes appear in later models automobiles are recalled infrequently buildings are expensive to remodel Adapting to a pre existing environment May be difficult to change the environment however if the environment changes the software system is expected to adapt With software the pressures are greater software functionality plus its malleable It is difficult to plan for arbitrary change Kenn eth M Anderson 2000 10 Changeability Other instances of conformity April 19 2000 Kenn eth M Anderson 2000 functionality is what often needs to be changed 11 April 19 2000 Kenn eth M Anderson 2000 12 Invisibility What about X Software is invisible and unvisualizable Brooks argues that past breakthroughs solve accidental difficulties In contrast to things like blueprints here geometry helps to identify problems and optimizations of space Its hard to diagram software We find that one diagram may consist of many overlapping graphs rather than just one New hopefuls flow of control flow of data patterns of dependency etc This lack of visualization deprives the engineer from using the brain s powerful visual skills April 19 2000 Kenn eth M Anderson 2000 High level languages Time Sharing Programming Environments Ada OO Programming AI expert systems automatic programming etc 13 April 19 2000 Promising Attacks on Essence Brooks reflects on the No Silver Bullet paper ten years later Don t develop software at all Lots of people have argued that there methodology is the silver bullet Rapid Prototyping Brooks buys in If so they didn t meet the deadline of 10 years Incremental Development Other people misunderstood what Brooks calls obscure writing grow not build software Great designers Kenn eth M Anderson 2000 14 No Silver Bullet Refired Buy vs Build April 19 2000 Kenn eth M Anderson 2000 For instance when he said accidental he did not mean occurring by chance 15 April 19 2000 Kenn eth M Anderson 2000 16 The size of accidental effort Obtaining the Increase Some people misunderstood his point with the 9 10ths figure Some people interpreted Brooks as saying that the essence could never be attacked Brooks doesn t actually think that accidental effort is 9 10th of the job That s not his point however he said that no single technique could produce an order of magnitude increase by itself its much smaller than that As a result reducing it to zero which is probably impossible will not give you an order of magnitude improvement April 19 2000 Kenn eth M Anderson 2000 17 Obtaining the Increase continued Brooks states We will surely make substantial progress over the next 40 years an order of magnitude over 40 years is hardly magical April 19 2000 Kenn eth M Anderson 2000 19 He argued that several techniques in tandem could achieve that goal but that requires industry wide enforcement and discipline April 19 2000 Kenn eth M Anderson 2000 18
View Full Document
Unlocking...