The Laws of Software Engineering in just Five Bits

the laws of

faculty of engineering university of porto

Software Engineeringin just five bits

joão pascoal faria hugo sereno ferreira&

I the fundamental

limit of requirements

requirements end where the liberty of the developer begins.

h

II the three f’s of

priority management

functionality,

fidelity,

efficiency.

h

III the gray dichotomy

structural abstraction can always be solved by introducing a level of

indirection*

*corollary. there is no performance problem that cannot be solved by eliminating a level of indirection.

h

Jim Gray

IV the archimedean principle

h

a software system built on top of a weak architecture will sink due to

the weight of its own success.

V the human-machine

polarisation principle

h

artificial intelligence is always better than natural stupidity.

VI the redundancy conundrum

h

redundancy is a major source of errors… though it can

also be used to reveal them.

VII the kaner non-symmetry

h

a program which perfectly meets a lousy specification is a lousy

program.

Cem Kaner

VIII the incomplete

by design principle

h

for all practical purposes, it’s impossible to prove the

correctness of all software*

*corollary. development is a conjecture-making activity.

IX the murphy approximation

h

all programs have errors*

* the number of errors (n) in a given program can be approximated by n > k, where k is any unsigned integer.

Murphy’s Laws

X the boris lemma

h

bugs lurk in corners and congregate at boundaries.

Boris Beizer

XI the management

uncertainty principle

h

it’s not possible to simultaneously fix the cost, duration and quality of

a software project.

XII the deadline amplification

h

the estimated time remaining to finish any given project is a

monotonically increasing function.

XIII the second zeno paradox

h

what remains to be done is not enough to satisfy the customer*

*customer’s satisfaction is a moving target.

XIV the non-acceptance

conservation principle

h

the x% that remains to be implemented have (100-x)% of importance to the customer.

XV the agile peculiarity

h

there’s always time to make more changes until there’s no more

time to make changes*

* it’s always the last change that blew it up.

XVI the social responsibility of a

software engineer

h

if the world ends in a catastrophic scenario… who you gonna call?

the software engineers*

* because they did it!

XVII the dijkstra observation

h

if debugging is the process of removing software bugs, then

programming must be the process of putting them in.

Edsger Dijkstra

XVIII the pattis zen

h

when debugging, novices insert corrective code; experts remove

defective code.

Richard Pattis

XIX the adams pitfall

h

a common mistake that people make when trying to design something

completely foolproof is to underestimate the ingenuity of

complete fools.

Douglas Adams

XX the ninety-ninety rule

h

the first 90% of the code accounts for the first 90% of the

development time. The remaining 10% of the code accounts for the other

90% of the development time.

Tom Cargill

XXI the wirth’s law

h

software is getting slower more rapidly than hardware becomes

faster.

Wirth

XXII the mencken razor

h

for every complex problem, there is a solution that is simple,

neat, and wrong.

H. L. Mencken

XXIII the bergman dilation

h

there's never enough time to do it right, but there's always enough time to do it over.

Jack Bergman

XXIV the bruce transmutation

h

any sufficiently advanced bug is indistinguishable from a feature.

Bruce Brown

XXV the hofstadter's recursion

h

development always take more time than estimated, plus that of the

hofstadter’s recursion.

XXVI the eisenhower paradox

h

i have always found that plans are useless, but planning is

indispensable.

Dwight Eisenhower

XXVII the first law of

code documentation

h

no comments

XXVIII the hoare duality

h

there are two ways of constructing a piece of software: one is to make it so

simple that there are obviously no errors, and the other is to make it so complicated

that there are no obvious errors.

Tony Hoare

XXIX the michael solution

h

if you automate a mess, you get an automated mess.

Rod Michael

XXX the alan forced congruency

h

it is easier to change the specification to fit the program

than vice versa.

Alan Perlis

XXXI the heisenberg requirement

h

the more stable a requirement is considered, the greater the

probability it is changed.

XXXII the norman strange

attractor

h

the hardest part of design… is keeping features out.

Donald Norman

XXXII+I the divine equivalence

h

software and cathedrals both rely on the same process*

* first you build, then you pray.