The document lists various laws and principles related to software engineering, emphasizing the complexities and uncertainties inherent in the field. It covers topics such as requirement limitations, error sources, project management challenges, and the paradoxes faced during software development. The document serves as a reminder of the intricacies and often unpredictable nature of engineering software.

1. the laws of
faculty of engineering university of porto
Software Engineering
in just five bits
joão pascoal faria hugo sereno ferreira&

2. I
the fundamental
limit of requirements
requirements end where the
liberty of the developer begins.
h

3. II
the three f’s of
priority management
functionality,
fidelity,
efficiency.
h

4. 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

5. 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.

6. V
the human-machine
polarisation principle
h
artificial intelligence is always
better than natural stupidity.

7. VI
the redundancy conundrum
h
redundancy is a major source
of errors… though it can
also be used to reveal them.

8. VII
the kaner non-symmetry
h
a program which perfectly meets a
lousy specification is a lousy
program.
Cem Kaner

9. 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.

10. 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

11. X
the boris lemma
h
bugs lurk in corners and
congregate at boundaries.
Boris Beizer

12. XI
the management
uncertainty principle
h
it’s not possible to simultaneously
fix the cost, duration and quality of
a software project.

13. XII
the deadline amplification
h
the estimated time remaining to
finish any given project is a
monotonically increasing function.

14. 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.

15. XIV
the non-acceptance
conservation principle
h
the x% that remains to be
implemented have (100-x)% of
importance to the customer.

16. 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.

17. 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!

18. 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

19. XVIII
the pattis zen
h
when debugging, novices insert
corrective code; experts remove
defective code.
Richard Pattis

20. 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

21. 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

22. XXI
the wirth’s law
h
software is getting slower more
rapidly than hardware becomes
faster.
Wirth

23. XXII
the mencken razor
h
for every complex problem,
there is a solution that is simple,
neat, and wrong.
H. L. Mencken

24. 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

25. XXIV
the bruce transmutation
h
any sufficiently advanced bug is
indistinguishable from a feature.
Bruce Brown

26. XXV
the hofstadter's recursion
h
development always take more time
than estimated, plus that of the
hofstadter’s recursion.

27. XXVI
the eisenhower paradox
h
i have always found that plans
are useless, but planning is
indispensable.
Dwight Eisenhower

28. XXVII
the first law of
code documentation
h
no comments

29. 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

30. XXIX
the michael solution
h
if you automate a mess, you get an
automated mess.
Rod Michael

31. XXX
the alan forced congruency
h
it is easier to change the
specification to fit the program
than vice versa.
Alan Perlis

32. XXXI
the heisenberg requirement
h
the more stable a requirement is
considered, the greater the
probability it is changed.

33. XXXII
the norman strange
attractor
h
the hardest part of design…
is keeping features out.
Donald Norman

34. XXXII+I
the divine equivalence
h
software and cathedrals both rely
on the same process*
* first you build, then you pray.