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 completely "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 2 - 3% / month (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