PRESENTATION 2

1. PRESENTATION 2 • No Silver Bullet: • Essence and Accidents of • Software Engineering • By Frederick P. Brooks, Jr. CS 5391 Survey of Software Engineering Chang-Ho Lee

2. Before Starting • This article was published on April of 1987 - consider the state of software engineering in that time period - future in context • No silver bullet “silver bullet: something that acts as a magical weapon; esp. one that instantly solves a long-standing problem” in the Merriam Webster’s Dictionary

3. No Silver Bullet “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, and in simplicity.” by Brooks - There is no magical cure for the software crisis.

4. No Silver Bullet “A disciplined, consistent effort to develop, propagate, and exploit innovations should indeed yield an order of magnitude improvement.” - There is no royal road, but there is a road.

5. Essence and Accidents • Brooks divides difficulties of software technology into two categories - Essence: difficulties, which are inherent in the nature of software - Accidents: difficulties, which are related to the production of software but not inherent

6. Essence • A construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions “I believe the hard part of building software is the specification, design, and testing of this conceptual construct, not in the labor of representing it and testing the fidelity for the representation.”

7. Essence (continued) • Brooks divides the essence into four subcategories - Complexity - Conformity - Changeability - Invisibility

8. Complexity • Software entities are amazingly complex •No Two parts are alike - unlike computers, buildings, or cars - if they are alike, we make the two similar parts into a subroutine • SW system have a huge number of states - orders of magnitude more states than computers do • Scaling-up is not merely done thru repetition of common elements in larger sizes - elements interacting in some linear fashion drive up complexity, more than linear

9. Complexity (continued) • You cannot abstract away the complexity - if you can, then abstract away the essence because complexity is the part of essence - mathematics and physical sciences abstract away complex details because the complexities are not the essence of the domains

10. Complexity (continued) • Consequences • Technical problems - communication among team members: product flaws, cost overruns, schedule delays - enumerating all possible states of program: much less understanding, unreliability - extending programs to new functions without creating side effects - unvisualized states

11. Complexity (continued) • Management problems - hard overview: impede conceptual integrity - hard to find or control all the loose ends - tremendous learning and understanding burden

12. Conformity • SW must conform to an existing and imperfect world - but no unifying principles or simplified explanations - complexity is arbitrary: differ from interface to interface, from time to time - designed by different people • Complexity is added by conformity to other interfaces and this cannot be easily engineered out

13. Changeability • SW is constantly asked to be changed • Other things are too, however manufactured things are rarely changed - the changes appear in later models - automobiles are recalled infrequently - buildings are expensive to remodel • With software, the pressure are greater - software of a system embodies its functions that are the parts that need to be changed - software can be changed more easily: low cost - software is embedded in a cultural matrix: applications, user, laws, …

14. Invisibility • Software is invisible and unvisualizable • In contrast to things like blueprints - geometric abstractions are extremely helpful to architects, mechanical designers and chemists • the reality of SW is not embedded in space - hard to diagram SW - one diagram may consist of many overlapping graphs rather than just one: flow of control, flow of data, patterns of dependency, time sequence, name space relationships - these are not even planner

15. Invisibility (continued) • The lack of visualization deprives the engineer from using the brain’s powerful visual skills - not only impedes the process of design within one mind, but also it severely hinders communication among mind

16. Accidents • Accidents: difficulties that attend to software production • Three past breakthroughs attacked accidental difficulties • High-level languages - frees a program from much of its accidental complexity ex) abstract program and concrete machine program - furnish all the constructs the programmer imagines in abstract program

17. Accidents (continued) • Time-sharing - preserves immediacy - hence, enables one to maintain an overview of complexity • Unified programming environments - Unix - integrated libraries, unified file formats

18. Hopes for the Silver • Ada and high-level languages • OOP • AI • Expert System • Automatic Programming • Graphic Programming • Work Stations, etc

19. Promising Attacks on Essence • Buy - don’t develop software • Requirement Refinement and Rapid Prototyping - decide what to build - the detailed technical requirement, including all the interfaces to people, to machines and to other software systems - no other part is more difficult to rectify later

20. Promising Attacks on Essence • Grow, Don’t build SW - building is a bottom up process - growing is top-down process - a system should first be made to run, then it should be fleshed out, bit by bit • Great Designers - good designs come from great designers

21. Conclusion • Brooks argued • No silver bullet • The improvement we have witnessed to date are not effective solution • Several techniques can achieve goal, but that requires industry-wide enforcement and discipline • Brooks pointed us in right direction to go for improvement of software development