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
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