Credits

Slides adapted from the slides for the book "Software Engineering: The Current Practice" by Václav Rajlich © 2012 by Václav Rajlich

Programmers Face Difficulties

• Memory management
• Pointers
• Types and subtypes
• IDE or other tools crash/corrupt
• Process differences

Category of Difficulties

Accidental difficulties

• Difficulties of past/current/future technologies
• Quirks of the o.s., languages, compilers, and processes

Category of Difficulties

Essential difficulties

• A subset of the essential properties of software
• No easy answers

Essential Difficulties

• Complexity
• Invisibility
• Changeability
• Conformity
• Discontinuity

Essential Difficulty: Complexity

Programs are among the most complex systems ever created

• Short-term memory limitation, Miller's Law, original article
• Strategies:
• Simplified models
• Decomposition
• As-Needed approach
• Abstraction

Essential Difficulty: Invisibility

Software is abstract

• We cannot use most of our senses for software comprehension
• Use of other senses (e.g., software visualization) require work to understand
• E.g., MosaiCode

Essential Difficulty: Changeability

Software is easy to change

• Software is constantly changing
• Yesterday's comprehension may be obsolete
• Continuous effort to keep up

Essential Difficulty: Conformity

Large systems include more than software, e.g., hardware, users, domain

• Software glues it together, reflects the larger domain
• … adding more complexity

Essential Difficulty: Discontinuity

People understand linear or semi-linear systems

• E.g., faucet knobs
• Software is discontinuous, i.e., a small change in the input can result in a significant change in the output
• E.g., one wrong calculation can be minor or significant, and there is no way to predict

Beginning of Software

• Separated from hardware in the 1950s
• Distinct technology
• Independent product
• Original programmers were hardware engineers and mathematicians
• Used ad-hoc techniques from their former fields

Definition: Paradigm

Paradigm: "Coherent tradition of scientific research"

• Thomas S. Kuhn's "The Structure of Scientific Revolutions"
• Includes law, theory, application, instrumentation, terminology, research agenda, textbooks, norms, curricula, culture, etc.
• Not only the ideas but also investment in those ideas
• Often overused, e.g., "object-oriented paradigm"

Anomaly Creates Dilemma

Anomaly: an important fact that directly contradicts the old paradigm

• Dilemma: disregard anomaly vs. paradigm shift
• Shifting paradigm requires abandoning substantial investment
• Anomaly must be compelling

Paradigm Shift

Discontinuity in the development of the discipline (i.e., a revolution)

• Example paradigm shifts in the natural sciences

Resistance to Paradigm Shift

• Advantages of the new paradigm are disputed
• Extend old paradigm to accommodate anomalies
• "band-aid" approaches to fix old paradigm
• Accumulated knowledge and investment may lose significance, and some knowledge may be lost
• New paradigm only ultimately "wins" when a generation change occurs
• Paradigm shifts may be unsuccessful

Paradigm Shift: the 1970s

Anomaly: Previous ad-hoc techniques did not scale

• Brooks Mythical Man-Month
• Demands of the (new) IBM OS/360 O.S. strained the limits of programmers, project managers, and resources of IBM
• Paradigm Shift established the discipline of software engineering
• Dealt with the complexity of software
• Software Design became important
• Introduced the Waterfall metaphor

Waterfall Paradigm

Waterfall

Anomaly

Waterfall did not solve the problems of software development

• Requirements volatility, e.g., Requirements for IT change at a rate of 24 - 36% / year (doubling at least every ??? and ??? years, respectively)

Paradigm Shift: ~2000

New lifespan models emphasize software evolution

• Staged model of software lifespan
• Based on data from real systems over long periods
• Iterative development, Rational Unified Process, agile development, eXtreme Programming, Scrum
• Shift even in DOD software

Paradigm Summary

• Waterfall paradigm
• Tried to freeze requirements for the duration of development
• Deal with volatility by rigidity
• Led to too many project failures
• New paradigm
• Emphasizes software evolution and iteration
• Interoperability and complexity cause volatility
• Volatility is a consequence of essential properties

All Paradigms Coexist

• Ad-Hoc paradigm
• Still used by some individual developers
• Programming as an art rather than engineering
• E.g., small games, small utilities
• Waterfall paradigm
• Small or short-lived projects
• Unusually stable requirements and environments
• Management may insist on it
• Iterative paradigm
• The mainstream of modern development