the laws of

S o f twar e E n gine ering

in just five bits

joo pascoal faria & hugo sereno ferreira

faculty of engineering university of porto

I
the fundamental
limit of requirements

h
requirements end where the
liberty of the developer begins.

II
the three fs of
priority management

h
functionality,
fidelity,
efficiency.

III
the gray dichotomy

h
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.
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, its
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.

Murphys Laws

X
the boris lemma

h
bugs lurk in corners and
congregate at boundaries.

Boris Beizer

XI
the management
uncertainty principle

h
its 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*
*customers 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
theres always time to make more
changes until theres no more
time to make changes*
* its 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 wirths 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
hofstadters 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.