The Laws of Software Engineering in just Five Bits
the laws of
faculty of engineering university of porto
in just five bits
joão pascoal faria hugo sereno ferreira&
limit of requirements
requirements end where the
liberty of the developer begins.
the three f’s of
the gray dichotomy
structural abstraction can always be
solved by introducing a level of
*corollary. there is no performance problem that
cannot be solved by eliminating a level of indirection.
the archimedean principle
a software system built on top of a
weak architecture will sink due to
the weight of its own success.
artificial intelligence is always
better than natural stupidity.
the redundancy conundrum
redundancy is a major source
of errors… though it can
also be used to reveal them.
the kaner non-symmetry
a program which perfectly meets a
lousy specification is a lousy
by design principle
for all practical purposes, it’s
impossible to prove the
correctness of all software*
*corollary. development is a conjecture-making activity.
the murphy approximation
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.
the boris lemma
bugs lurk in corners and
congregate at boundaries.
it’s not possible to simultaneously
fix the cost, duration and quality of
a software project.
the deadline amplification
the estimated time remaining to
finish any given project is a
monotonically increasing function.
the second zeno paradox
what remains to be done is not
enough to satisfy the customer*
*customer’s satisfaction is a moving target.
the x% that remains to be
implemented have (100-x)% of
importance to the customer.
the agile peculiarity
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.
the social responsibility of a
if the world ends in a catastrophic
scenario… who you gonna call?
the software engineers*
* because they did it!
the dijkstra observation
if debugging is the process of
removing software bugs, then
programming must be the
process of putting them in.
the pattis zen
when debugging, novices insert
corrective code; experts remove
the adams pitfall
a common mistake that people make
when trying to design something
completely foolproof is to
underestimate the ingenuity of
the ninety-ninety rule
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.
the wirth’s law
software is getting slower more
rapidly than hardware becomes
the mencken razor
for every complex problem,
there is a solution that is simple,
neat, and wrong.
H. L. Mencken
the bergman dilation
there's never enough time to do
it right, but there's always
enough time to do it over.
the bruce transmutation
any sufficiently advanced bug is
indistinguishable from a feature.
the hofstadter's recursion
development always take more time
than estimated, plus that of the
the eisenhower paradox
i have always found that plans
are useless, but planning is
the first law of
the hoare duality
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.
the michael solution
if you automate a mess, you get an
the alan forced congruency
it is easier to change the
specification to fit the program
than vice versa.
the heisenberg requirement
the more stable a requirement is
considered, the greater the
probability it is changed.
the norman strange
the hardest part of design…
is keeping features out.
the divine equivalence
software and cathedrals both rely
on the same process*
* first you build, then you pray.