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 20^th century) are listed below at the time they became widespread, (courtesy Wikipedia  ):

—1960s:

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)

1970s:

C and UNIX (1973)  
“Waterfall” Model, sequential development process
System Development Methodology
SCCS, the first version-control system, publicly released. (1977)

1980s:

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)

1990s:

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)

2000s:

Subversion VCS released (2000)
Agile Unified Process [AUP] (2005)
Disciplined agile delivery [DAD]
Git & Mercurial DVCSs released (2005)
iPhone - First modern mobile device (2007)

2010s:

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

Tools:
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 ):

Programming-in-the-Small	Programming-in-the-Large
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 concern	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

Subcategories:

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)

Subcategories:

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.

Games:

Hit oriented, like movies
Only one major version
Killer deadlines trump maintainability.

Throwaway:

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.

Hint: IEEE SWEBOK

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.