Fundamental knowledge

The halting problem

Fundamental computer science knowledge

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

Software engineering

What knowledge do we teach today

Agile and Scrum methodologies

UML or DDD modelling methods

Object-oriented design patterns

Tools like Git, Travis, Docker

Software engineering

The search for fundamental knowledge

What is impossible to build?

Can we guarantee cost or correctness?

Not a formal mathematical problem

Can we say anything certain at all?

Historically situated Software Engineering

History and critical analysis of software development tools and practices

Programming in 1950

Hacker culture of programming

Programming in the 1950s was a black art, a private arcane matter (...), each problem required a unique beginning at square one, and the success of a program depended primarily on the programmer's
private techniques and inventions.

NATO 1968 Conference on Software Engineering

Programming started transition from a craft for a long-haired priest-hood to a real engineering discipline.

Software engineering

Agreement on problems, not on solutions

Follow-up NATO 1969 Conference failed

Mathematical culture favours proofs

Business culture favours management

Roots of a cultural divide?

Apply industrial methods of production to software

Control over budgets, scheduling, workforce

Process should eliminate reliance on individuals

Paradigm Change (1987)

Product oriented

Software is seen as a product
serving some fixed use case

Fundamental knowledge

Agile methodology in historical context

Context, response and problems

Minority process oriented paradigm

Pushback against managerial culture

Application crisis of 1990s

Modelling in context

Modelling using UML

• Fully specify system up-front
• Managerial control over process
• Becomes communication tool

Modelling via code and tests

• Rise of engineering culture
• Supports process-oriented approach
• Keeping model up-to-date

What is more complex software system to build?

Chess engine that can consistently win against grandmasters?

Accounting system that calculates VAT in UK and France?

IBM System/360

Operating system
for a wide range of
IBM machines

Massively delayed
due to complexity
and conflicting requirements

Software complexity

No Silver Bullet (Fred 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 (1986)

Essential complexity

• Complexity of essential logic
• Specification is as complex as program implementing it

Fundamental Software Engineering principle

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.

Star Wars (1980s)

Fully automatic software system to track and shoot down Soviet nuclear missiles

Can reliable system to do this be built?

Sources of complexity

Analog systems
Small change in input causes small change in output
Analog computers of 1930s, audio synthesizers

Digital systems with repeated components
Non-linear, but we can test components in isolation
CPU units and much of modern hardware

Digital systems without repetition
Non-linear and very hard to test
Any modern software system!

Fundamental Software
Engineering Principle

Complex software can only be mastered if it is developed progressively, with the aid of extensive testing, and then operated more or less continually in a somewhat lenient and forgiving environment.

Arguments that count (2013)

Defense would be unreliable

Since we have no spare planets
on which to fight trial nuclear
wars, testing of a global ABM
system is impossible.

Developed into the Patriot system

Metaphors for programming

Engineering metaphor

• Managerial response to crisis
• Focus on planning and control
• Each metaphor has misfits

Why metaphors for programming matter?

New way of thinking and shift of emphasis

Urban planning

Complexity of software

• Analog systems
• Repetitive digital systems
• Non-repetitive digital

Complexity of cities

• Problems of simplicity
• Problems of unorganized complexity
• Problems of organized complexity

Dealing with problems
of organized complexity

City processes are too complex to be abstracted. Explore them in full complexity.

One unaverage value tells us more than statistic.

Adaptable buildings

Evolve and need maintenance

• But none are designed to evolve
• Different layers evolve differently
• How to teach maintenance?

Choosing a material

• Traditional materials are well understood
• It should look bad before it acts bad

It's own discipline

Meeting of cultures

• Managerial culture
• Engineering culture
• Mathematical culture

We Have Never
Been Modern

We must rework our thinking to conceive of a "Parliament of Things" where natural and social phenomena, and the discourse about them are not seen as separate objects, but as hybrids made by the interaction of people, things and concepts.

Summary

Fundamental Software Engineering principles

• History and critical analysis of software development tools and practices
• Interaction between cultures:
  managerial, mathematical, engineering
• "Parliament of Things" made by interaction

Tomas Petricek, University of Kent and fsharpWorks
tomas@tomasp.net | @tomaspetricek

Reading list