Grown-up Software Development

A Summary and Methodological Principles

Immature discipline

In spite of its 50 year history, software development is a curious immature affair. To do better we must recognise the great variety in our problems and products, we must think consciously about development risks, we must focus our attention where it matters, we must learn from experience, and we must be masters, not pedants, of development methods.– Michael Jackson, “Problem Frames”, p333.

State of the art

• 50 years on we have– Programming languages– Compilers– IDEs– GUI builders– Common applications– The Web

• But software quality suggests the discipline is still in its infancy

Panaceas & silver bullets

– Structured programming– Flow charts– Structured methods– 4GLs– Prototyping– Development processes to support the

entire lifecycle

• Humbug and snake oil

Become a master

• A master– Recognises the need for different

notations and techniques– Knows when to use which technique– Is not a pedant – can tailor methods– Must understand the rules very well

Understand failure

• Engineers ask “how/when will this fail, what happens when it does?”

• Software only fails because it is wrong; this is a development failure

• reason about the consequences:– How hard is this to get right?– How/when will I know if it’s wrong?– How bad will it be if it’s wrong?– How easily can it be fixed if it’s wrong?

Amatuerism

• Failing to consult or use existing specialised knowledge of a problem domain

• What algorithm do you use for a cruise control? – ask a control engineer.

• Don’t invent financial auditing rules yourself for a finance system

• Etc.

Complexity

• Real problems are complex• Postpone composition until you have

mastered the components, or• Postpone the solution until you have

analysed and understood the problem• That’s what’s wrong with top-down

– Reverse composition of something we don’t understand to create components that are probably wrong

Frames in Perspective

• PFs let you classify development problems• Guide decomposition by showing a

repertoire of subproblems you know how to handle

• They DON’T WORK for every kind of problem in every situation– Pure maths: no domains or interfaces– GUI – use a standard GUI builder– Compiler – use established texts on compiler

design

Principles of Methodology

• Beneficent difficulty*• Close-fitting frames*• Commensurate care• Deferred invention*• Dispassionate methodology*• Domain relevance• Frame exploitation*• Problem sensitivity• Uniform mood

Commensurate care

The care taken in each aspect of a development should be proportional to PD where P is the probability that it will go wrong, and D is the size of the disaster if it does.

• If you need to fudge something, do it where it will do no serious harm

Domain relevance

Everything that’s relevant to the requirements must appear in some part of the application domain

• If it doesn’t appear in domain descriptions, the system cannot report on it, control it, etc.

Problem sensitivity

A method for solving problems must be closely expressed in terms of the problems it can help you solve

• If a method doesn’t talk about the problem, how can it help you solve it?– The method used in designing the program is to break the specified

problem down into a number of sub-problems expressed in English. The same idea is then used to break down each sub-problem into further sub-problems. The method is applied successively until each of the sub-problems can be readily and easily expressed in the programming language. This is called programming by stepwise refinement.

– Gak!!! Antithesis of sensitivity

Uniform mood

Never mix indicative and optative moods in the same description

• Indicative mood describes the natural properties that the domains possess regardless of the system

• Optative mood describes what the system is required to do.

To summarise

• We have:– Tools for project planning, project

management, risk assessment, team management

– Change management strategies– Development methods– Life cycle models– Formal proofs

Continued

• We also have an immature discipline that repeatedly delivers bad systems

• We must– employ principles of methodology– Become masters and not pedants– Avoid method enthusiasts– Analyse and structure problems

• So, go forth and do some good!