1. Overview

Art is never finished, only abandoned.
— Anonymous

Fig. 1.1 Vitruvian Man. 

This quote (sometimes attributed to Leonardo da Vinci), applies to many types of creative work including software development. Unfortunately perfection is never achieved, only approached, as we close in bit-by-bit to its asymptote 

Let’s begin from a birds-eye view of the subject before digging in.

1.1. Timeline

To find out where the industry is headed it is useful to know where it’s been. Significant developments and techniques in software engineering history (from the latter half of the 20th century) are listed below at the time they became widespread, (courtesy Wikipedia  ):

  • Von Neumann architecture  (1945),
    (stored-program, instructions and data in a shared memory/bus)

  • First generation programming language:

    • Hardware dependent machine code

    • Entered via control panel switches (gulp)

  • Second generation:

    • Assembly language, conditional jumps (1949)

    • Human readable, converted to machine code.

  • Third generation:

    • Automatic memory management (1959) (LISP)

    • Structured programming (1960, 1968)
      (FORTRAN, ALGOL, subroutines and blocks)

    • Machine independence (portability)

  • C and UNIX (1973)  

  • “Waterfall” Model, sequential development process

  • System Development Methodology

  • SCCS, the first version-control system, publicly released. (1977)

  • Structured systems analysis and design method [SSADM] (1980), data modeling.

  • IBM PC ships (1981)

  • RCS, the second version-control system (1982)

  • GNU Manifesto published (1985)

  • Spiral Process Model (1986)

  • Object-oriented programming [OOP]
    (developed: 60s, popular: 90s)

  • Concurrent Versioning System (CVS) released (1990)

  • Rapid application development [RAD] (1991)

  • High-level dynamic scripting

  • Scrum (1986, 1995)

  • Cathedral and the Bazaar, The - Essay (1997)

  • Rational Unified Process [RUP] (1998)

  • ‘Extreme’ programming (1999)

  • Subversion VCS released (2000)

  • Agile Unified Process [AUP] (2005)

  • Disciplined agile delivery [DAD]

  • Git & Mercurial DVCSs released (2005)

  • iPhone - First modern mobile device (2007)

  • Continuous Integration & Delivery

  • Workplace domination by “lumber-sexuals”

1.2. Areas of Study

Software engineering knowledge may be further categorized. Consider these three types of knowledge, courtesy Eddie Burris at UMKC :


C++, Node.js, MySQL, SVN, Github, Jira, etc.

  • Ease: time consuming, but low effort.

  • Value: popularity, necessity

  • Half-life: ~5-10 years

Methods and Techniques:

Object-oriented programming, XP, Scrum, etc.

  • Ease: moderate challenge

  • Value: high, but short-term consequences moderate.

  • Half-life: ~20 years

Concepts, Principles:

Science, Engineering, Design, Management, Quality

  • Ease: require study and experience to master

  • Value: essential for innovation, less so for routine projects.

  • Half-life: ~50-100 years

Anyone can learn a tool in 21 hours, no? In this book we’ll focus on concepts rather than fashionable tools, as they are the foundation that will survive the span of a career.

1.3. Professional Development

Fresh from university (or parent’s basement, yuk yuk) you may have yet to work on a large team project as is common in industry. Here are a number of the differences compared to familiar school and hobby projects (courtesy Eddie Burris at UMKC ):



Individual working alone

Team working together

Small simple program
(<1k lines)

Large, complex system
(>10k lines)

Stable well-defined requirements

Changing, ill-defined requirements

Few users

Many users, conflicting needs

Stable external environment

Dynamic external environment

May use a single familiar tech

Heterogeneous technology

Can rewrite if needed

Asset to be leveraged for a decade+

Meets an immediate need

Able to grow over time and adapt

Runs in isolation

Interoperates with other systems

Code written from scratch
w/full control

Mix of COTS  and
custom components

Functional reqs are the primary

Non-functional reqs
(quality; performance) also

Further differences are explored in the next section.

1.4. Five+ Worlds

Something important is almost never mentioned in all the literature about programming and software development, and as a result we sometimes misunderstand each other.
— Joel Spolsky, Blogger/co-founder StackExchange 

Fig. 1.2 The DC Multiverse 

As mentioned in the previous chapter, Choose Your Adventure, “context is everything” when choosing methodology and strategy for a software project. Indeed, sometimes the good advice you’ll receive (including in this book) may not apply to your situation. Why is that?

Joel Spolsky described the problem in his essay, the “Five Worlds”  of software development. There are at least five. What are they?

External Software:

Describes software which is meant to be used by others—as many as possible.

  • Must be robust and “resilient to variation.”

  • Usability a priority


  • Shrinkwrap, at retail or downloadable.

  • Commercial web-based software

  • Open Source, partially fits here.

Internal Software:

Must work in one situation at one company.

  • Easier to develop.

  • Few customers to distribute cost:

    • Large investment doesn’t make sense.

    • Speed of development a priority

    • Usability a low priority

    • Captive audience (aka, deal with it)

  • “Sadly lots of internal software sucks pretty badly.” (Yup)


  • Consultingware, requires customization at high cost.

Embedded Software:
  • Electronics

  • Rarely if ever updated

  • High quality requirements (no second chances)

  • Speed more important than elegance

  • Usability is often lacking due to harsh restrictions.

  • Hit oriented, like movies

  • Only one major version

  • Killer deadlines trump maintainability.


The “one-offs” to get you from Point A to Point B.

  • No investment in quality or elegance.

Know Your World

Whenever you read one of those books about programming methodologies written by a full time software development guru/consultant, you can rest assured that they are talking about internal, corporate software development. Not shrinkwrapped software, not embedded software, and certainly not games. Why? Because corporations are the people who hire these gurus.
— Joel Spolsky, Blogger/co-founder StackExchange 

There ya have it. Again, don’t take advice you read here or in the linked resources as universal truths. The reason Spolsky’s advice sometimes clashed with other pundits in the industry: he was discussing commercial “shrinkwrap” development more often than not. Keep this in mind and help make the Internet “more civilized.”

While this particular book attempts a wider, more generic utility, remember “context is everything.”

Next, let’s look at software life cycles.

1.5. Lifecycle Planning

Every software-development effort goes through a "lifecycle," which consists of all the activities between the time that version 1.0 of a system begins life as a gleam in someone's eye and the time that version 6.74b finally takes its last breath on the last customer's machine. A lifecycle model is a prescriptive model of what should happen between first glimmer and last breath.
— Steve McConnell, Rapid Development (Ch. 7):

Fig. 1.3 A Software Development Lifecycle

A number of paradigms, methodologies, and frameworks in service to software engineering have been found notable over the years. To that end we have the Software Development Life Cycle, (SDLC for short) a traditional model for the series of phases a software project of significant size passes through during its lifetime.

The phases start with an analysis of a project’s requirements, followed by design and construction of the software, full testing and review, customer acceptance, and finally release. Ongoing maintenance and support continues—until the project’s end-of-life (EOL) date is reached, where it is finally abandoned, often in favor of a new version, rethinking of the problem, or market alternative.

While there are many models to choose from, we begin here because it allows us to take the various activities of software engineering one at a time before attempting to interleave them in later chapters. Idealistic in nature, the SDLC is not strictly applied as often as it once was, however it continues as a foundation for comprehension of the wider field.

In the following chapters, we’ll take a look at each phase in turn. Software project requirements are discussed next.



Fig. 1.4 Serving a mean curry.

References to the “IEEE SWEBOK,” are made in upcoming chapters, quite a mouthful of an acronym, no? The first half refers to the Institute of Electrical and Electronics Engineers , often pronounced “I-triple-E.” Despite IEEE’s name they also develop and promote standards regarding Software Engineering, under their “Computer Society” . The second half, SWEBOK stands for the “Software Engineering Body of Knowledge”  a compendium of the best practices that the software industry has learned so far.

IEEE offers certification  on this knowledge base, for associates (graduates) as well as experienced professionals.

See also:  Introducing Project Cartoon


Fig. 1.5 The Tree-Swing Project.

To err is human; to really foul things up requires a computer.
— Bill Vaughan 

To the right is the first of a series of comics from Project Cartoon , which describe the planning and creation of a “tree swing” project. To be clear, the comic illustrates a cynical take on the industry—the panes may be a bit too true at times.  ;-)

If you enjoy them, consider patronizing the site.