No silver bullet essence and accidents of software engineering

1. by Frederick P. Brooks, Jr.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Difficulties in Essence of Software -
conformity
 Conformity: must
interface with existing
systems.
2/2/2016 Arun_Banotra (a_b431) 15

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. 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. 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. 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. 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. 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. 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. 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. Difficulties in Essence of Software-
invisibility
 Invisibility: cannot
visualize all aspects at
once.
2/2/2016 Arun_Banotra (a_b431) 24

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. 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. 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. Contd..
2/2/2016 Arun_Banotra (a_b431) 28
silicon chips
have diagram
Buildings
have plans
UML
class

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 2/2/2016 Arun_Banotra (a_b431) 47
Thank You!