the laws of software engineering in just five bits
TRANSCRIPT
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.