Today s Lecture Discuss the No Silver Bullet paper Brook s reflections on it after nine years No Silver Bullet Kenneth M Anderson Foundations of Software Engineering CSCI 5828 Spring Semester 2001 Guest Lecture March 14 2001 No Silver Bullet Kenneth M Anderson 2001 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 March 14 2001 Kenneth M Anderson 2001 2 essence difficulties inherent in the nature of software accidents difficulties related to the production of software 3 March 14 2001 Kenneth M Anderson 2001 4 An Order of Magnitude The Essence 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 March 14 2001 Kenneth M Anderson 2001 complexity conformity changeability invisibility Lets consider each in turn 5 March 14 2001 Software entities are amazingly complex 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 Kenneth M Anderson 2001 6 Complexity continued Complexity March 14 2001 Kenneth M Anderson 2001 7 March 14 2001 Kenneth M Anderson 2001 8 Conformity Complexity continued Problems resulting from complexity difficult team communication product flaws cost overruns schedule delays personnel turnover loss of knowledge March 14 2001 unenumerated states lots of them lack of extensibility complexity of structure unanticipated states security loopholes project overview is difficult impedes conceptual integrity Kenneth M Anderson 2001 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 March 14 2001 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 Kenneth M Anderson 2001 10 Changeability Other instances of conformity March 14 2001 Kenneth M Anderson 2001 functionality is what often needs to be changed 11 March 14 2001 Kenneth M Anderson 2001 12 Invisibility What about X Brooks argues that past breakthroughs solve accidental difficulties Software is invisible and unvisualizable 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 Ada OO Programming AI expert systems automatic programming etc This lack of visualization deprives the engineer from using the brain s powerful visual skills March 14 2001 Kenneth M Anderson 2001 13 Promising Attacks on Essence Kenneth M Anderson 2001 14 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 Other people misunderstood what Brooks calls obscure writing Incremental Development grow not build software For instance when he said accidental he did not mean occurring by chance Great designers Kenneth M Anderson 2001 March 14 2001 No Silver Bullet Refired Buy vs Build March 14 2001 High level languages Time Sharing Programming Environments 15 March 14 2001 Kenneth M Anderson 2001 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 March 14 2001 Kenneth M Anderson 2001 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 March 14 2001 Kenneth M Anderson 2001 19 He argued that several techniques in tandem could achieve that goal but that requires industry wide enforcement and discipline March 14 2001 Kenneth M Anderson 2001 18
View Full Document
Unlocking...