PS 1 No Silver Bullets AN OVERVIEW OF

PS 1: No Silver Bullets AN OVERVIEW OF PAPERS BY BROOKS (87) AND BERRY (04)

No Silver Bullets Essence and Accidents of Software Engineering 2 FREDERICK P. BROOKS, JR. , 1987 Based on presentations by F. P Brooks Devon Simmonds Computer Science Department University of North arolina Wilmington Software Engineering Spring 2009

The Software Werewolf 3 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 We want the silver bullet to kill the monster something to make software costs drop as rapidly as computer hardware costs do. Software Engineering Spring 2009

There Is No Silver Bullet! 4 “As we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either essence, technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity” Goal: ”In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed. ” Software Engineering Spring 2009

Essential vs. Accidental Difficulties 5 Essential: a characteristic of software Difficulties inherent in the nature of software Data sets, relationships among them, algorithms, and function invocation Inherent properties of the essence of modern software system: Complexity, Conformity, Changeability, Invisibility Accidental: a problem in today’s production methods Difficulties related to the actual production process. Note: This doesn’t mean “by chance”! Software Engineering Spring 2009

Complexity 6 No two parts are alike Huge number of states Complexity grows nonlinearly with size Can’t know the whole domain, process, or system Unlike other disciplines, we can’t abstract away the complexity because it is essential Math, physics: complexities ignored in the models were not the essential properties of the phenomena. Introduces technical and managerial problems leading to unreliability Complexity Software Size Software Engineering Spring 2009

“Software has order of magnitude more states than computers" 7 How many paths? loop < 20 X There about 1014 (~520) possible paths! If we execute one test per millisecond, it would take 3, 170 years to test this program!! Software Engineering Spring 2009

Consequences of Complexity 8 Communication overhead: cost overruns, schedule delays Large number of states: unreliability overview is hard to find and control all the loose ends. creates a tremendous learning and understanding burden Complex function: poor usability Complex structure: poor maintainability Software Engineering Spring 2009

Conformity 9 Software development lacks unifying rules and theories. man made not God made. Software must conform to arbitrary limitations imposed by humans (e. g. business rules) institutions and systems Software arrives late in system design Software viewed as most changeable It’s hard to plan for arbitrary changes that will occur late in development Software Engineering Spring 2009

Changeability 10 Software is easier to change than hardware or cars Changes during development Changes after deployment New features Software lives longer than hardware Conform to new vehicles of opportunity (computers, displays etc. . ) People underestimate difficulties of change Software Engineering Spring 2009

Invisibility 11 The code is invisible and unvisualizable Software reality not embedded in space: no ready geometric representation. Structure is terribly complex Structure is hidden There’s only the external input/output view silicon chips have diagram Software Engineering Spring 2009 Buildings have plans UML class

Accidental Difficulties Already Solved 12 High level languages Powerful stroke for software productivity, reliability, & simplicity Removed the low level complexities Benefits of further improvement is limited Time sharing 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 Integrated programming environments Use of libraries, unified file formats, pipes, filters etc Software Engineering Spring 2009

Is There Any Hope? Yes! 13 “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. ” Technical developments that are most often advanced as potential silver bullets Ada & High Level Languages Advances. OOP AI Expert Systems Etc. Software Engineering Spring 2009

Things To Try 14 Reuse: “buy, don’t build” Requirements improvement and rapid prototyping Incremental development: (“grow don’t build”) Better SE training : grow “great designers” “My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be Future Software Engineers similarly nurtured and rewarded. Not only salary, but the perquisites of recognition-office size, furnishings, personal technical equipment, travel funds, staff support-must be fully equivalent. ” Multiple coordinated techniques Software Engineering Spring 2009

Summary 15 No one advance will give a 10 x improvement All the accidental difficulties have been solved No one advance will address essential difficulties But perhaps we can learn to better exploit what we’ve learned Software Engineering Spring 2009

The Inevitable Pain of Software Development: Why There Is No Silver Bullet 16 DANIEL M. BERRY, 2004 Software Engineering Spring 2009

About the paper 17 This paper tries to get to the root of why any given new programming technique has not improved productivity very much. This paper is…an attempt “to analyze why some ideas were or were not successful” with the choice of “were not”. Software Engineering Spring 2009

Programming Then and Now (~40 years perspective) 18 I remember doing requirements analysis at the same time as I was doing the programming in the typical seat-of-the-pants build-it-and-ﬁx-it-until-it-works Basically, method of those days: 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. programming felt like skiing down a narrow downhill valley with an avalanche following me down the hill and gaining on me. Nowadays, we follow more systematic methods. However, the basic feelings have not changed. Software Engineering Spring 2009

The Problem by Berry 19 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. Software Engineering Spring 2009

The Search for a Silver Bullet 20 Brooks: 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. That is, the requirements are the essence, while the language, tools, and methods used are the accidents. what is so difficult about understanding requirements? it should be possible to sit down with the customer and users, ask a few questions, understand the answers, and then synthesize a complete requirements speciﬁcation. Software Engineering Spring 2009

Requirements Change 21 Two things are known about requirements: They will change. 1. Software will always have to be modiﬁed, to capture the changed requirements. There ain’t no way to stop change of requirements. 2. They will be misunderstood. Software will always have to be modiﬁed, to capture the changes imposed by better understanding, as the misunderstandings are discovered. Software Engineering Spring 2009

Maintenance of application software (Bennett Lientz and Burton Swanson ‘ 78) 22 Software Engineering Spring 2009

Expected number of errors in a program as a function of time (Laszlo Belady and Meir Lehman ‘ 75, ’ 86) 23 Belady-Lehman (B-L) upswing, it is very difficult to change anything without adding more errors than have been ﬁxed by the change the software at its most bug-free Release change Software Engineering Spring 2009

Purpose of Methods 24 Example: Information Hiding attempts to structure a system into modules such thateach implementation change results in changing only the code, and not the interface, of only one module. ? Software Engineering Spring 2009 ?

Development Models and Global Methods 25 Example development models and general programming methods to identify their painful parts. Example Models Waterfall Requirements Engineering. Example general methods Structured Programming Extreme Programming, Program Generation Rapid Prototyping Formal Methods Software Engineering Spring 2009

Bottom line (by Berry) 26 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 Software Engineering Spring 2009

The Pain (More details from Berry’s paper) 27 The rest of the slides summarize the following sections: Development Models and Global Methods Speciﬁc Methods and Techniques Documentation Tools and Environments Software Engineering Spring 2009

Development Models and Global Methods 28 Watefall–an attempt to put discipline into the software development process. The model would work if the programmers could understand a stage thoroughly and document it fully before going on to the next stage Pain - when the full requirements are learned only after signiﬁcant implementation has been carried out Pain - when there is signiﬁcant repeated backtracking as new requirements are continually discovered Software Engineering Spring 2009

Development Models and Global Methods 29 Structured Programming Work as promised for the development of the ﬁrst version of any software Patching destroys the relation between the structured development and the code The former is no longer accurate documentation of the abstractions leading to the code. Requirements Engineering Spend sufﬁcient time up front, before designing and coding, to anticipate all possible requirements Data show that errors found during requirements analysis cost one order of magnitude less to ﬁx than errors found during coding and two orders of magnitude less to ﬁx than errors found during operation At least two ways of carrying out requirement engineering Big. Modeling Up Front (BMUF) Tries to anticipate all requirements – Pain during RE Initial Requirements Up Front (IRUF) Embrace the change and decide on the basis of business value whether or not to do the change Pain in re-implementation necessitated by the change e. g. refactoring Software Engineering Spring 2009

Development Models and Global Methods 30 Extreme Programming preplanning that is the cornerstone of each the various disciplined programming methods, is a waste of time. XP consists in simply building to the requirements that are understood at the time that programming commences the requirements are given, with executable test cases. Pain -test cases are not always written : In general writing test cases is hard in particular before we know what the code is supposed to do when a requirement comes along that does not ﬁt in the existing architecture software is refactored. Refactoring consists in stepping back, considering the new current full set of requirements and ﬁnding a new simplest architecture that ﬁts the entire set. Software Engineering Spring 2009

Development Models and Global Methods 31 Program Generation and Domain-Speciﬁc Approaches Program generators are generally for application domains that are well enough understood that major requirement surprises that force refactoring of the system’s architecture, are unlikely. In more understood domains, programs are really more manufactured than they are programmed. In less understood domains, domain-speciﬁc approaches provide enough structure, a stable architecture that the domain has become a true engineering discipline, like aircraft, automobile, and bridge engineering. Software Engineering Spring 2009

Development Models and Global Methods 32 Rapid Prototyping A means to identify requirements, to try out various ideas, to do usability testing, etc. To the extent that it succeeds, it delays and moderates the B-L upswing. The pain is to throw the prototype out and to start a new when implementation starts. When the prototype’s architecture is used for the production software, the very ﬁrst production version is brittle, hard to modify, and prone to breaking whenever a change is made. Software Engineering Spring 2009

Development Models and Global Methods 33 Formal Methods Formal program development methodss Start with a formal speciﬁcation of the software to be built Once a formal speciﬁcation has been written it can be subjected to veriﬁcation that it meets higher level formally stated requirements, such as security criteria. Any code written for the implementation can be veriﬁed as correct with respect to the speciﬁcation. Sometimes implementing code can be generated directly from the speciﬁcation. The Pain (by some)- writing of a formal speciﬁcation Pain (by others) - all the veriﬁcation that needs to be done Pain (Berry) - the work dealing with changed requirements Speciﬁcation has to be changed with the same difﬁculties as changing code: ﬁnding all other parts of the speciﬁcation affecting or affected by the change at hand. Software Engineering Spring 2009

Speciﬁc Methods and Techniques 34 Speciﬁc methods and techniques each attacking a speciﬁc problem of software engineering Examples Inspection Formal technical reviews (for example, inspections) result in fewer production bugs, lower maintenance costs, and higher software success rates. Pain -unwilling to plan the effort required to recognize bugs in their early stage even though bugs found in the ﬁeld cost as much as 200 times more to correct The Daily Build Open Sourcing The main advantage is that the software has a world-wide legion of merciless inspectors and bug ﬁxers Goodness of ﬁt is measured not only by how well it solves the problem but also by how consistent it is with all other changes that are being done Software Engineering Spring 2009

Documentation 35 Documentation is painful. It requires that people stop the analysis, design, or coding work that they are doing and to write their ideas down on the spot. If they do not stop to document, they forget the details Often, there is no time to document. The shipping deadline is intimidating. -> documentation never happens. If any of it happens, it quickly gets out of date as the program continues to change Later, the programmers who must make changes have no information or poor out-of-date information about the requirements of, the architecture of, the design of, the rationale behind, the test plans for, and the commentary about the code. Since they do not know what documentation to trust, they trust none of it. Hard time ﬁnding the code and tests affecting and affected by the changes. Again, the irony is that the very process that the documentation helps is the process that undermines the validity of the documentation. Software Engineering Spring 2009

Tools and Environments 36 The general pain of all these tools and environments is remembering to use them… For example, conﬁguration management systems depend on programmers’ checking modules out for working on them and on programmers’ checking modules back in when the programmers are ﬁnished with working on them. When a programmer fails to check a module out, check a module back in, or to meet with another, the system loses control and the completeness and consistency it promises cannot be guaranteed any more. Software Engineering Spring 2009

Bottom line (by Berry) 37 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 Software Engineering Spring 2009