no silver bullet essence and accidents of software engineering

47
No Silver Bullet: Essence and Accidents of Software Engineering by Frederick P. Brooks, Jr.

Upload: arun-banotra

Post on 09-Apr-2017

210 views

Category:

Education


3 download

TRANSCRIPT

Energy-Efficient Scheduling for Multicore Systems with Bounded Resources

No Silver Bullet: Essence and Accidents of Software Engineering

by Frederick P. Brooks, Jr.

2/2/2016Arun_Banotra (a_b431)2 Outline

IntroductionEssential vs. Accidental DifficultiesInherent Difficulties in SoftwareBreakthroughs To Solve Accidental DifficultiesHopes for the SilverMethods for Dealing with Essential DifficultiesFuture Work Not from Research PaperConclusion

2/2/2016Arun_Banotra (a_b431)3 IntroductionThere is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity (1986).

Silver bullet : a way to defeat werewolves.

Generally any straightforwardsolution perceived to have extreme effectiveness.

Contd..The paper compares software to hardware:The anomality is not that software progress is so slow, but that computer hardware progress is so fast.

Frederick P. Brooks made the argument that there is no silver bullet that can kill the werewolf software projects

2/2/2016Arun_Banotra (a_b431)4

The Software WerewolfSoftware is like a werewolfit looks normal until the moon comes out and it turns into a monsterMissed deadlines Blown budgets Buggy software

We want the silver bullet to kill the monsterSomething to make software costs drop as rapidly as computer hardware costs do.

2/2/2016Arun_Banotra (a_b431)5

2/2/2016Arun_Banotra (a_b431)6

Essence and Accidents

The essence is what the software does and the accidents are the technology by which the software does the essence or by which the software is developed.

E.g : In a calculator doing calculation is essence and calculation algorithm used to do that is accidents.

6

2/2/2016Arun_Banotra (a_b431)7

Essential vs. Accidental DifficultiesEssential: a characteristic of software Difficulties inherent in the nature of softwareData sets, relationships among them, algorithms, and function invocationInherent properties of the essence of modern software system: Complexity, Conformity, Changeability, Invisibility Accidental: a problem in todays production methods Difficulties related to the actual production process.

2/2/2016Arun_Banotra (a_b431)8

Contd..Essence vs. accident in software developmentWe can get rid of accidental difficulties in developing softwareGetting rid of these accidental difficulties will increase productivityFor example using a high level programming language instead of assembly language programmingThe difficulty we remove by replacing assembly language with a high-level programming language is not an essential difficulty of software development, It is an accidental difficulty brought by inadequacy of assembly language for programming

2/2/2016Arun_Banotra (a_b431).

Contd..9Essence vs. accident in software developmentBrooks argues that software development is inherently difficultThe hard part of building software is the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.Even if we remove all accidental difficulties which arise during the translation of this conceptual construct (design) to a representation (implementation), still at its essence software development is difficult

2/2/2016Arun_Banotra (a_b431)10

Inherent Difficulties in SoftwareSoftware has the following properties in its essence:ComplexityConformityChangeabilityInvisibility

Since these properties are not accidental representing software in different forms do not effect them.

Difficulties in Essence of Software - complexity

Complexity: due to interaction of components, number of possible states grows much faster than lines of code.2/2/2016Arun_Banotra (a_b431)11

Contd..No two parts are alikeHuge number of statesComplexity grows nonlinearly with sizeCant know the whole domain, process, or systemUnlike other disciplines, we cant abstract away the complexity because it is essentialMath, physics: complexities ignored in the models were not the essential properties of the phenomena.

Introduces technical and managerial problems leading to unreliability

2/2/2016Arun_Banotra (a_b431)12

Consequences of ComplexityTechnical Problems:communication among team membersenumerating (much less understanding) of all possible states of the program

Management problems:conceptual integrity is hard to achievelearning curve: personnel turnover becomes disaster

2/2/2016Arun_Banotra (a_b431)13

Consequences of ComplexityCommunication overhead: cost overruns, schedule delaysLarge number of states: unreliabilityoverview is hardhard to find and control all the loose ends.creates a tremendous learning and understanding burdenComplex function: poor usabilityComplex structure: poor maintainability

2/2/2016Arun_Banotra (a_b431)14

Difficulties in Essence of Software - conformity

Conformity: must interface with existing systems.

2/2/2016Arun_Banotra (a_b431)15

Contd..Conformity comes from the fact that all new software must conform to the way things where done in the past, because it is hard to change everyone.Main reason software must conform is that it is new on the scene.Software is required to conform to itsOperating environmentHardwareOften last kid on blockPerceived as most conformable

2/2/2016Arun_Banotra (a_b431)16

Contd..

Most of the time software systems have to interface with an existing system

Even for a new system, the perception is that, it is easier to make software interfaces conform to other parts of the system .

We need not to change the whole existing system because of new software.

2/2/2016Arun_Banotra (a_b431)17

Difficulties in Essence of Software - Changeability

Changeability: must model changing real world, increase functionality, run on new hardware.2/2/2016Arun_Banotra (a_b431)18

Contd..Change originates with New applications, users, machines, standards, lawsHardware problemsSoftware is easy to change, unlike hardware

Example: Once an Intel processor goes to the production line, the cost of replacing it is enormous (Pentium bug cost half billion dollars)If a Microsoft product has a bug, the cost of replacing it is negligible. Just put the new download on a webpage and ask users to update their software

2/2/2016Arun_Banotra (a_b431)19

Contd..Being able to change something after it has been constructed is a new concept.

Software must be able to change, and the complexity of the systems becomes harder to follow.

All successful software gets changed.

Successful software also survives beyond the normal life of the machine vehicle for which it is first written for.

2/2/2016Arun_Banotra (a_b431)20

Expectations from changeabilitySoftware is easier to change than hardware Changes during developmentChanges after deploymentNew featuresSoftware lives longer than hardware

Note: People underestimate difficulties of change

2/2/2016Arun_Banotra (a_b431)21

Changeability is not an AdvantageAlthough it sounds like, finally, software has an advantage over hardware, the effect of changeability is that there is more pressure on changing the software

Since software is easy to change software gets changed frequently and deviates from the initial designadding new featuressupporting new hardware

2/2/2016Arun_Banotra (a_b431)22

Contd..

Conformity and Changeability are two of the reasons why reusability is not very successful in software systems

Conformity and Changeability make it difficult to develop component based software, components keep changing

2/2/2016Arun_Banotra (a_b431)23

Difficulties in Essence of Software- invisibility

Invisibility: cannot visualize all aspects at once. 2/2/2016Arun_Banotra (a_b431)24

Contd..Software has no 3-D way on which it can be laid out.

Software has data flow charts, time sequence graphs, and other types of things which are hard to understand.

Communication becomes hard because each person my see it a different way.

No obvious representationE.g., familiar geometric shapes

2/2/2016Arun_Banotra (a_b431)25

Contd..The code is invisible and unvisualizableSoftware reality not embedded in space: no ready geometric representation.

Structure is terribly complex and hidden.

Software does not have one map or graph, it will have multiple maps and graphs.

Theres only the external input/output view

2/2/2016Arun_Banotra (a_b431)26

Invisibility and Visualization tools Visualization tools for computer aided design are very helpful to computer engineersSoftware tools that show the layout of the circuit (which has a two-dimensional geometric shape) makes it much easier to design a chip

Visualization tools for software are not as successfulThere is nothing physical to visualize, it is hard to see an abstract conceptThere is no physical distance among software components that can be used in mapping software to a visual representationUML and similar languages are making progress in this area

2/2/2016Arun_Banotra (a_b431)27

Contd..

2/2/2016Arun_Banotra (a_b431)28silicon chips have diagram

Buildings have plans

UML class

SummaryAccording to Brooks, there are essential difficulties in software development which prevents significant improvements in software engineering:Complexity; Conformity; Changeability; Invisibility

He argues that an order of magnitude improvement in software productivity cannot be achieved using a single technology due to these essential difficulties

2/2/2016Arun_Banotra (a_b431)29

Past Breakthroughs Solved Accidental Difficulties

High-Level Languages

Time-Sharing

Integrated programming environments - Use of libraries, unified file formats, pipes, filters etc

2/2/2016Arun_Banotra (a_b431)30

High-level LanguagesThe most powerful thing to happen to software development ever.

It allows that some types on data structures, operation, classes etc, to be used by any machine.

Programmers dont have to develop software for individual machines.

2/2/2016Arun_Banotra (a_b431)31

Contd..Powerful stroke for software productivity, reliability, & simplicity

Removed the low level complexities

Benefits of further improvement is limited

2/2/2016Arun_Banotra (a_b431)32

Time-SharingMost observers credit the time-sharing improvement to better programmers, and better programming languages.

Programs run faster because of the high-level languages.

Do not have to accommodate for machine language anymore.

2/2/2016Arun_Banotra (a_b431)33

Contd..Increased turnaround time and productivity of programmer

Improvement is not as much as that of high-level language

System response time is no longer an issue

2/2/2016Arun_Banotra (a_b431)34

Is There Any Hope for Silver Bullet? Yes! 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.

2/2/2016Arun_Banotra (a_b431)35

Hopes for the SilverOOP:HierarchicalData hidingHelps in design, but do not solve design complexityProblem

AI (expert systems)May be very useful.

2/2/2016Arun_Banotra (a_b431)36

Contd..

Automatic programming: generation of a program from problem specificationUsed successfully for very specific tasks (differential equations,)Hard to imagine having a general solution

Graphical programming:No hope, for software is difficult to visualize

2/2/2016Arun_Banotra (a_b431)37

Contd..Program verificationMight reduce the program-testing load, not eliminate itA lot of workCan establish that a program meet its specification. But the hardest part is to get such complete and consistent specification!

2/2/2016Arun_Banotra (a_b431)38

Contd..Better workstations, environments and toolsare welcomed, but magical enhacements cannot be expected.

Buy vs. Build Discusses the process of wide-spread use of software today compared to 60-s, adopting procedures to existing software.We can buy a software and can distribute to others as there is no replica fee instead of building for each user.

2/2/2016Arun_Banotra (a_b431)39

Contd..Requirements refinement and rapid prototypingThe hardest single part of building a software system is deciding precisely what to buildMust show product to customer to get complete specificationNeed for iterative feedback

2/2/2016Arun_Banotra (a_b431)40

Contd..Incremental developmentGrow systems, dont build themEasy backtrackingEarly prototypes

Great designersThe difference between the great and the average approach an order of magnitudeGives hints as to how to grow great designersGood design can be taught; great design cannotBottom line: Nurture great designers

2/2/2016Arun_Banotra (a_b431)41

Some Methods for Dealing with Essential DifficultiesComplexityBreakdown of system into manageable modulesBreakdown of development process into phases, tasks, and subtasksTeam programmingChangeability and ConformityChange management Configuration managementInvisibilityuse of multiple models, for many views of system

2/2/2016Arun_Banotra (a_b431)42

Future Work Not part of research paper

In 2004 Daniel M. Berry again focussed on this topic that why there is no silver bullet.

His paper tries to get to the root of why any given new programming technique has not improved productivity very much.

2/2/2016Arun_Banotra (a_b431)43

Contd..Method of those days(Brooks Time):discover some requirements, code a little, discover more requirements, code a little more, etc, until the coding was done; test the whole thing, discover bugs or new requirements, code some more, etc.Nowadays, we follow more systematic methods. However, the basic feelings have not changed.

2/2/2016Arun_Banotra (a_b431)44

Bottom line (by Berry)I no longer get excited over any new language, development model, method, tool, or environment that is supposed to improve programming

The most important work is addressing requirements, changes, and the psychology and sociology of programming

2/2/2016Arun_Banotra (a_b431)45

ConclusionNo one advance will give a 10x improvementAll the accidental difficulties can be solved.Even if we remove all accidental difficulties still at its essence software development is difficult.There is still a hope for silver for solving software related problems and thus for the betterment of later issues.The real problem of software engineering is dealing with ever-changing requirements. No model, method, artifact, or tool offered to date has succeeded to overcome this problem.

2/2/2016Arun_Banotra (a_b431)46

2/2/2016Arun_Banotra (a_b431)47 Thank You!