Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
by Frederick P. Brooks, Jr.
2/2/2016 Arun_Banotra (a_b431) 2
Outline
 Introduction
 Essential vs. Accidental Difficulties
 Inherent Difficulties in...
2/2/2016 Arun_Banotra (a_b431) 3
Introduction
 “There is no single development, in either technology or
management techni...
Contd..
 The paper compares software to hardware:
 The anomality is not that software progress is so
slow, but that comp...
The Software Werewolf
 Software is like a werewolf—it looks normal until the moon
comes out and it turns into a monster
...
2/2/2016 Arun_Banotra (a_b431) 6
Essence and Accidents
• The essence is what the software does and the accidents are
the t...
2/2/2016 Arun_Banotra (a_b431) 7
Essential vs. Accidental Difficulties
• Essential: a characteristic of software
• Difficu...
2/2/2016 Arun_Banotra (a_b431) 8
Contd..
• Essence vs. accident in software development
• We can get rid of accidental dif...
2/2/2016 Arun_Banotra (a_b431)
.
Contd..
9
• Essence vs. accident in software development
• Brooks argues that software de...
2/2/2016 Arun_Banotra (a_b431) 10
Inherent Difficulties in Software
• Software has the following properties in its essence...
Difficulties in Essence of Software -
complexity
 Complexity: due to
interaction of components,
number of possible states...
Contd..
 No two parts are alike
 Huge number of states
 Complexity grows nonlinearly with size
 Can’t know the whole d...
Consequences of Complexity
 Technical Problems:
 communication among team members
 enumerating (much less understanding...
Consequences of Complexity
 Communication overhead: cost overruns, schedule delays
 Large number of states: unreliabilit...
Difficulties in Essence of Software -
conformity
 Conformity: must
interface with existing
systems.
2/2/2016 Arun_Banotra...
Contd..
 Conformity comes from the fact that all new software must
conform to the way things where done in the past, beca...
Contd..
 Most of the time software systems have to interface with an
existing system
 Even for a new system, the percept...
Difficulties in Essence of Software -
Changeability
 Changeability: must
model changing real world,
increase functionalit...
Contd..
 Change originates with
 New applications, users, machines, standards, laws
 Hardware problems
 Software is ea...
Contd..
 Being able to change something after it has been
constructed is a new concept.
 Software must be able to change...
Expectations from changeability
 Software is easier to change than hardware
 Changes during development
 Changes after ...
Changeability is not an Advantage
 Although it sounds like, finally, software has an advantage
over hardware, the effect ...
Contd..
 Conformity and Changeability are two of the reasons why
reusability is not very successful in software systems
...
Difficulties in Essence of Software-
invisibility
 Invisibility: cannot
visualize all aspects at
once.
2/2/2016 Arun_Bano...
Contd..
 Software has no 3-D way on which it can be laid out.
 Software has data flow charts, time sequence graphs, and
...
Contd..
 The code is invisible and unvisualizable
 Software reality not embedded in space: no ready
geometric representa...
Invisibility and Visualization tools
 Visualization tools for computer aided design are very
helpful to computer engineer...
Contd..
2/2/2016 Arun_Banotra (a_b431) 28
silicon chips
have diagram
Buildings
have plans
UML
class
Summary
 According to Brooks, there are essential difficulties in
software development which prevents significant
improve...
Past Breakthroughs Solved Accidental
Difficulties
 High-Level Languages
 Time-Sharing
 Integrated programming environme...
High-level Languages
 The most powerful thing to happen to software
development ever.
 It allows that some types on data...
Contd..
• Powerful stroke for software productivity, reliability, &
simplicity
• Removed the low level complexities
• Bene...
Time-Sharing
 Most observers credit the time-sharing improvement to
better programmers, and better programming languages....
Contd..
• Increased turnaround time and productivity of
programmer
• Improvement is not as much as that of high-level
lang...
Is There Any Hope for Silver Bullet?
Yes!
“A disciplined, consistent effort to develop,
propagate, and exploit these innov...
Hopes for the Silver
 OOP:
 Hierarchical
 Data hiding
Helps in design, but do not solve design complexity
Problem
 AI ...
Contd..
 “Automatic” programming: generation of a program
from problem specification
 Used successfully for very specifi...
Contd..
 Program verification
 Might reduce the program-testing load, not
eliminate it
 A lot of work
 Can establish t...
Contd..
 Better workstations, environments and tools
 are welcomed, but magical enhacements cannot be
expected.
 Buy vs...
Contd..
 Requirements refinement and rapid prototyping
 “The hardest single part of building a software
system is decidi...
Contd..
 Incremental development
 Grow systems, don’t build them
 Easy backtracking
 Early prototypes
 Great designer...
Some Methods for Dealing with
Essential Difficulties
 Complexity
 Breakdown of system into manageable
modules
 Breakdow...
Future Work – Not part of research
paper
 In 2004 Daniel M. Berry again focussed on this topic that
why there is no silve...
Contd..
Method of those days(Brook’s Time):
 discover some requirements,
 code a little,
 discover more requirements,
...
Bottom line (by Berry)
I no longer get excited over any new language, development
model, method, tool, or environment that...
Conclusion
 No one advance will give a 10x improvement
 All the accidental difficulties can be solved.
 Even if we remo...
2/2/2016 Arun_Banotra (a_b431) 47
Thank You!
Upcoming SlideShare
Loading in …5
×

No silver bullet essence and accidents of software engineering

No silver bullet essence and accidents of software engineering

  • Login to see the comments

No silver bullet essence and accidents of software engineering

  1. 1. by Frederick P. Brooks, Jr.
  2. 2. 2/2/2016 Arun_Banotra (a_b431) 2 Outline  Introduction  Essential vs. Accidental Difficulties  Inherent Difficulties in Software  Breakthroughs To Solve Accidental Difficulties  Hopes for the Silver  Methods for Dealing with Essential Difficulties  Future Work – Not from Research Paper  Conclusion
  3. 3. 2/2/2016 Arun_Banotra (a_b431) 3 Introduction  “There 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 straightforward solution perceived to have extreme effectiveness.
  4. 4. 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/2016 Arun_Banotra (a_b431) 4
  5. 5. The Software Werewolf  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. 2/2/2016 Arun_Banotra (a_b431) 5
  6. 6. 2/2/2016 Arun_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.
  7. 7. 2/2/2016 Arun_Banotra (a_b431) 7 Essential vs. Accidental Difficulties • 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.
  8. 8. 2/2/2016 Arun_Banotra (a_b431) 8 Contd.. • Essence vs. accident in software development • We can get rid of accidental difficulties in developing software • Getting rid of these accidental difficulties will increase productivity • For example using a high level programming language instead of assembly language programming • The 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
  9. 9. 2/2/2016 Arun_Banotra (a_b431) . Contd.. 9 • Essence vs. accident in software development • Brooks argues that software development is inherently difficult • The 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
  10. 10. 2/2/2016 Arun_Banotra (a_b431) 10 Inherent Difficulties in Software • Software has the following properties in its essence: • Complexity • Conformity • Changeability • Invisibility • Since these properties are not accidental representing software in different forms do not effect them.
  11. 11. 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/2016 Arun_Banotra (a_b431) 11
  12. 12. Contd..  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 2/2/2016 Arun_Banotra (a_b431) 12
  13. 13. Consequences of Complexity  Technical Problems:  communication among team members  enumerating (much less understanding) of all possible states of the program  Management problems:  conceptual integrity is hard to achieve  learning curve: personnel turnover becomes disaster 2/2/2016 Arun_Banotra (a_b431) 13
  14. 14. Consequences of Complexity  Communication overhead: cost overruns, schedule delays  Large number of states: unreliability  overview is hard  hard to find and control all the loose ends.  creates a tremendous learning and understanding burden  Complex function: poor usability  Complex structure: poor maintainability 2/2/2016 Arun_Banotra (a_b431) 14
  15. 15. Difficulties in Essence of Software - conformity  Conformity: must interface with existing systems. 2/2/2016 Arun_Banotra (a_b431) 15
  16. 16. 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 its  Operating environment  Hardware  Often “last kid on block”  Perceived as most conformable 2/2/2016 Arun_Banotra (a_b431) 16
  17. 17. 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/2016 Arun_Banotra (a_b431) 17
  18. 18. Difficulties in Essence of Software - Changeability  Changeability: must model changing real world, increase functionality, run on new hardware. 2/2/2016 Arun_Banotra (a_b431) 18
  19. 19. Contd..  Change originates with  New applications, users, machines, standards, laws  Hardware problems  Software 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/2016 Arun_Banotra (a_b431) 19
  20. 20. 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/2016 Arun_Banotra (a_b431) 20
  21. 21. Expectations from changeability  Software is easier to change than hardware  Changes during development  Changes after deployment  New features  Software lives longer than hardware  Note: People underestimate difficulties of change 2/2/2016 Arun_Banotra (a_b431) 21
  22. 22. Changeability is not an Advantage  Although 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 design  adding new features  supporting new hardware 2/2/2016 Arun_Banotra (a_b431) 22
  23. 23. 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/2016 Arun_Banotra (a_b431) 23
  24. 24. Difficulties in Essence of Software- invisibility  Invisibility: cannot visualize all aspects at once. 2/2/2016 Arun_Banotra (a_b431) 24
  25. 25. 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 representation  E.g., familiar geometric shapes 2/2/2016 Arun_Banotra (a_b431) 25
  26. 26. Contd..  The code is invisible and unvisualizable  Software 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.  There’s only the external input/output view 2/2/2016 Arun_Banotra (a_b431) 26
  27. 27. Invisibility and Visualization tools  Visualization tools for computer aided design are very helpful to computer engineers  Software 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 successful  There is nothing physical to visualize, it is hard to see an abstract concept  There is no physical distance among software components that can be used in mapping software to a visual representation  UML and similar languages are making progress in this area 2/2/2016 Arun_Banotra (a_b431) 27
  28. 28. Contd.. 2/2/2016 Arun_Banotra (a_b431) 28 silicon chips have diagram Buildings have plans UML class
  29. 29. Summary  According 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/2016 Arun_Banotra (a_b431) 29
  30. 30. Past Breakthroughs Solved Accidental Difficulties  High-Level Languages  Time-Sharing  Integrated programming environments - Use of libraries, unified file formats, pipes, filters etc 2/2/2016 Arun_Banotra (a_b431) 30
  31. 31. High-level Languages  The 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 don’t have to develop software for individual machines. 2/2/2016 Arun_Banotra (a_b431) 31
  32. 32. Contd.. • Powerful stroke for software productivity, reliability, & simplicity • Removed the low level complexities • Benefits of further improvement is limited 2/2/2016 Arun_Banotra (a_b431) 32
  33. 33. Time-Sharing  Most 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/2016 Arun_Banotra (a_b431) 33
  34. 34. 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/2016 Arun_Banotra (a_b431) 34
  35. 35. 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/2016 Arun_Banotra (a_b431) 35
  36. 36. Hopes for the Silver  OOP:  Hierarchical  Data hiding Helps in design, but do not solve design complexity Problem  AI (expert systems)  May be very useful. 2/2/2016 Arun_Banotra (a_b431) 36
  37. 37. Contd..  “Automatic” programming: generation of a program from problem specification  Used 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/2016 Arun_Banotra (a_b431) 37
  38. 38. Contd..  Program verification  Might reduce the program-testing load, not eliminate it  A lot of work  Can establish that a program meet its specification. But the hardest part is to get such complete and consistent specification! 2/2/2016 Arun_Banotra (a_b431) 38
  39. 39. Contd..  Better workstations, environments and tools  are 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/2016 Arun_Banotra (a_b431) 39
  40. 40. Contd..  Requirements refinement and rapid prototyping  “The hardest single part of building a software system is deciding precisely what to build”  Must show product to customer to get complete specification  Need for iterative feedback 2/2/2016 Arun_Banotra (a_b431) 40
  41. 41. Contd..  Incremental development  Grow systems, don’t build them  Easy backtracking  Early prototypes  Great designers  “The difference between the great and the average approach an order of magnitude”  Gives hints as to how to grow great designers  Good design can be taught; great design cannot  Bottom line: Nurture great designers 2/2/2016 Arun_Banotra (a_b431) 41
  42. 42. Some Methods for Dealing with Essential Difficulties  Complexity  Breakdown of system into manageable modules  Breakdown of development process into phases, tasks, and subtasks  Team programming  Changeability and Conformity  Change management  Configuration management  Invisibility  use of multiple models, for many views of system 2/2/2016 Arun_Banotra (a_b431) 42
  43. 43. 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/2016 Arun_Banotra (a_b431) 43
  44. 44. Contd.. Method of those days(Brook’s 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/2016 Arun_Banotra (a_b431) 44
  45. 45. 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/2016 Arun_Banotra (a_b431) 45
  46. 46. Conclusion  No one advance will give a 10x improvement  All 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/2016 Arun_Banotra (a_b431) 46
  47. 47. 2/2/2016 Arun_Banotra (a_b431) 47 Thank You!

×