Literature Review

9/1/2014

1

NoSilverBullet

1

• Introduce thesis of Fred Brook’s "No Silver Bullet"

• Classic essay by Fred Brooks discussing “Why is SE so hard?”

No Silver Bullet

2

• “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.”— Fred Brooks, 1986

• i.e. There is no magical cure for the “software crisis”

Why? Essence and Accidents

3

• Brooks divides the problems facing software engineering into two categories

• essence: difficulties inherent, or intrinsic, in the nature of software

• accidents: difficulties related to the production of software

• Brooks argues that most techniques attack the accidents of software engineering

An Order of Magnitude

4

• In order to improve software development by a factor of 10

• first, the accidents of software engineering would have to account for 90% of the overall effort

• second, tools would have to reduce accidental problems to zero

• Brooks doesn't believe that the former is true…

• and the latter is nigh impossible because each new tool or technique solves some problems while introducing others

9/1/2014

2

The Essence

5

• Brooks divides the essence into four subcategories

• complexity

• conformity

• changeability

• invisibility

• Lets consider each in turn

Complexity (I)

6

• Software entities are amazingly complex

• No two parts (above statements) are alike

• Contrast with materials in other domains

• Large software systems have a huge number of states

• Brooks claims they have an order of magnitude more states than computers (i.e. hardware) do

• As the size of a system increases, both the number and types of parts increase exponentially

• the latter increase is the most significant

Complexity (II)

7

• You can't abstract away the complexity of the application domain. Consider:

• air traffic control, international banking, avionics software

• These domains are intrinsically complex and this complexity will appear in the software system as designers attempt to model the domain

• Complexity also comes from the numerous and tight relationships between heterogeneous software artifacts such as specs, docs, code, test cases, etc.

Complexity (III)

8

• Problems resulting from complexity

• difficult team communication

• product flaws; cost overruns; schedule delays

• personnel turnover (loss of knowledge)

• unenumerated states (lots of them)

• lack of extensibility (complexity of structure)

• unanticipated states (security loopholes)

• project overview is difficult

9/1/2014

3

Conformity (I)

9

• A lot of complexity facing software engineers is arbitrary

• Consider designing a software system to support an existing business process when

• a new VP arrives at the company

• The VP decides to “make a mark” on the company and changes the business process

• Our system must now conform to the (from our perspective) arbitrary changes imposed by the VP

Conformity (II)

10

• Other instances of conformity

• Having to integrate with a non-standard module interface

• Adapting to a pre-existing environment

• and if the environment changes (for whatever reason), you can bet that software will be asked to change in response

• Main Point: It is almost impossible to plan for arbitrary change;

• instead, you just have to wait for it to occur and deal with it when it happens

Changeability (I)

11

• Software is constantly asked to change

• Other things are too, however, manufactured things are rarely changed after they have been created

• instead, changes appear in later models; for example, automobiles are recalled only infrequently, and buildings are expensive to remodel

Changeability (II)

12

• With software, the pressure to change is greater

• in a project, it is functionality that is often asked to change and software EQUALS functionality (plus its malleable)

• clients of a software project often don't understand enough about software to understand when a change request requires significant rework of an existing system

• Contrast with more tangible domains, just imagine asking for a new layout of a house after the foundation has been poured

9/1/2014

4

Invisibility (I)

13

• Software is by its nature invisible; and it is difficult to design graphical displays of software that convey meaning to developers

• Contrast to blueprints: here geometry can be used to identify problems and help optimize the use of space

• But with software, its difficult to reduce it to diagrams

• UML contains 13 different diagram types to model class structure, object relationships, activities, event handling, software architecture, deployment, packages, etc.

Invisibility (II)

14

• Hard to get both a “big picture” view as well as details

• Hard to convey just one issue on a single diagram

• instead multiple concerns crowd and/or clutter the diagram hindering understanding

• This lack of visualization deprives the engineer from using the brain's powerful visual skills

Promising Attacks on the Essence

15

• Buy vs. Build

• Don't develop software when you can avoid it

• Rapid Prototyping

• Use to clarify requirements

• Incremental Development

• don't build software, grow it

• Great designers

• Be on the look out for them, when you find them, don't let go!

Quiz Yourself

16

• Essence or Accident?

• A bug in a financial system is discovered that came from a conflict in state/ federal regulations on one type of transaction

• A program developed in two weeks using a whiz bang new application framework is unable to handle multiple threads since the framework is not thread safe

• A new version of a compiler generates code that crashes on 32-bit architectures; the previous version did not

• A fickle customer submits 10 change requests per week after receiving the first usable version of a software system

9/1/2014

5

Software Engineering: More than just Programming

17

• It should now be clear that software engineering is more than just

• programming, data structures, algorithms, etc.

• It takes advantage of these very useful computer science techniques but adds

• quality concerns

• testing, code reviews, validation and verification of requirements

• process concerns

• Are we using the right software life cycle? Are we monitoring our ability to execute the process? Are we consistent? Are we getting better?

• reliance on tools, people, and support processes

• debugging, profiling, configuration management, deployment, issue tracking