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

Categories of Difficulties

  • Accidental difficulties
    • difficulties of past/current/future technologies
    • quirks of the o.s., languages, compilers, and processes
  • Essential difficulties
    • 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
  • Most of our senses cannot be used for comprehension
  • Use of our 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

  • Larger system includes 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., small change of input can result in huge change of output
    • E.g., one wrong calculation can be minor or major, and no way to predict

Beginning of Software

  • Separated from hardware in 1950’s
    • distinct technology
    • independent product
  • Original programmers were hardware engineers and mathematicians
    • Used ad-hoc techniques from their former fields

Definition: Paradigm

  • Thomas S. Kuhn “The Structure of Scientific Revolutions”
  • paradigm “Coherent tradition of scientific research”
    • includes law, theory, application, instrumentation, terminology, research agenda, textbooks, norms, curricula, culture of the field, etc.
    • not only the ideas, but also investment
  • often overused, e.g., “object-oriented paradigm”

Anomaly Creates Dilemma

  • anomaly is an important fact that directly contradicts the old paradigm”
  • Dilemma: disregard anomaly vs. paradigm shift
    • shifting paradigm requires abandoning large investment
    • anomaly must be compelling

Paradigm Shift

Resistance to Paradigm Shift

  • Advantages of the new paradigm are disputed
    • Old paradigm is extended 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 finally and completely “wins” when a generation change occurs
  • Paradigm shifts may be unsuccessful

Paradigm Shift: ~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 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 time 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
    • mainstream of modern development


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