Fundamental knowledge

What knowledge about software will remain
relevant in 100 years?

Fundamental software engineering knowledge

The halting problem

It is impossible to give a program
\(\Theta\) that, for any other program \(p\) decides whether \(p\) terminates or not.

Historically situated knowledge

Learning from
the successes and the failures
of the past

Learning from other disciplines

Is software engineering like real engineering, writing or urban planning?

What is more complex software system to build?

Chess engine that can consistently win against grandmasters?

Accounting system that calculates and pay VAT in UK and France?

IBM System/360

OS for a very wide
range of IBM machines

Led by Fred Brooks

Product
General, debugged, tested

System
Set of compatible tools

Sources of software complexity

No Silver Bullet (Brooks, 1986)

Much of the complexity [software engineer] must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must confirm.

No silver bullet (Brooks, 1986)

Essential complexity

• Large with no two parts alike
• Complexity of logic is essential
• Non-linear nature of software

Accidental complexity

• Imperfect programming tools
• Unless this is more than 9/10, order
  of magnitude improvement is impossible

Principle #2

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

IBM System/360

Significantly over budget
But it did not destroy IBM

Significantly delayed
But it shipped eventually

IBM hired more programmers
But it did not help

Unpartionable work Takes the same time regardless of number of people

Perfectly partionable Time decreases with number of people \(t=w/n\)

Requiring communication
Workers need to coordinate and be trained \(t=(w+k)/n\)

Complex task
Each worker needs to coordinate with each other \(t=w/n + k*n*(n-1)\)

Principle #3

Adding manpower to a late software project makes it later.

Further sources of complexity

We do not even know what software should do!

Every problem is unique with little repetition

There might not be a stopping rule

Solutions are not right or wrong

Social scientists call this Wicked Problems

Mythical Man-Month

Second system effect

This second is the most dangerous system a man ever designs

Throw one away

The first system may be too slow, too big, awkward to use, or all three.

No silver bullet (Brooks, 1986)

Buy versus build

• The most radical solution for constructing software is not to construct it at all.
• Can I use off-the-shelf solution?

Information hiding

Should all information be hidden or exposed?

Brooks (1975) - Regular info updates (microfiche!)

Parnas (1972) - Modules should hide their internals

OSS (1980s) - All source code should be available

Conceptual coherence

Simplicity proceeds from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata.

Conceptual integrity dictates that the design must proceed from one mind, or very small number of agreeing minds.

Software Engineering principles

Principle #1
Building a programming systems product
is ten times harder than building a program

Principle #2
No single development will lead to order-of-magnitude
improvement in productivity and reliability

Principle #3
Adding manpower to a late software project makes it later.

CO559: Software Engineering principles

What you should remember from this lecture

• Three principles of software engineering
• Essential and accidental complexity
• What can be done about it

Tomas Petricek
t.petricek@kent.ac.uk | @tomaspetricek

Books and papers

• Rebecca Slayton (2013). Arguments that count
• Nathan Ensmenger (2010). Computer boys take over
• Fred Brooks (1975). The mythical man-month
• Steve McConnell (1993). Code Complete: A Practical Handbook of Software Construction
• David Parnas (1985). Software aspects of strategic defence systems