Software Engineering Paradigms

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


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

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

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)

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