the laws of software engineering in just five bits
TRANSCRIPT
![Page 1: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/1.jpg)
the laws of
faculty of engineering university of porto
Software Engineeringin just five bits
joão pascoal faria hugo sereno ferreira&
![Page 2: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/2.jpg)
I the fundamental
limit of requirements
requirements end where the liberty of the developer begins.
h
![Page 3: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/3.jpg)
II the three f’s of
priority management
functionality,
fidelity,
efficiency.
h
![Page 4: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/4.jpg)
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
![Page 5: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/5.jpg)
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.
![Page 6: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/6.jpg)
V the human-machine
polarisation principle
h
artificial intelligence is always better than natural stupidity.
![Page 7: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/7.jpg)
VI the redundancy conundrum
h
redundancy is a major source of errors… though it can
also be used to reveal them.
![Page 8: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/8.jpg)
VII the kaner non-symmetry
h
a program which perfectly meets a lousy specification is a lousy
program.
Cem Kaner
![Page 9: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/9.jpg)
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.
![Page 10: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/10.jpg)
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
![Page 11: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/11.jpg)
X the boris lemma
h
bugs lurk in corners and congregate at boundaries.
Boris Beizer
![Page 12: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/12.jpg)
XI the management
uncertainty principle
h
it’s not possible to simultaneously fix the cost, duration and quality of
a software project.
![Page 13: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/13.jpg)
XII the deadline amplification
h
the estimated time remaining to finish any given project is a
monotonically increasing function.
![Page 14: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/14.jpg)
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.
![Page 15: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/15.jpg)
XIV the non-acceptance
conservation principle
h
the x% that remains to be implemented have (100-x)% of importance to the customer.
![Page 16: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/16.jpg)
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.
![Page 17: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/17.jpg)
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!
![Page 18: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/18.jpg)
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
![Page 19: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/19.jpg)
XVIII the pattis zen
h
when debugging, novices insert corrective code; experts remove
defective code.
Richard Pattis
![Page 20: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/20.jpg)
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
![Page 21: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/21.jpg)
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
![Page 22: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/22.jpg)
XXI the wirth’s law
h
software is getting slower more rapidly than hardware becomes
faster.
Wirth
![Page 23: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/23.jpg)
XXII the mencken razor
h
for every complex problem, there is a solution that is simple,
neat, and wrong.
H. L. Mencken
![Page 24: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/24.jpg)
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
![Page 25: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/25.jpg)
XXIV the bruce transmutation
h
any sufficiently advanced bug is indistinguishable from a feature.
Bruce Brown
![Page 26: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/26.jpg)
XXV the hofstadter's recursion
h
development always take more time than estimated, plus that of the
hofstadter’s recursion.
![Page 27: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/27.jpg)
XXVI the eisenhower paradox
h
i have always found that plans are useless, but planning is
indispensable.
Dwight Eisenhower
![Page 28: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/28.jpg)
XXVII the first law of
code documentation
h
no comments
![Page 29: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/29.jpg)
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
![Page 30: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/30.jpg)
XXIX the michael solution
h
if you automate a mess, you get an automated mess.
Rod Michael
![Page 31: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/31.jpg)
XXX the alan forced congruency
h
it is easier to change the specification to fit the program
than vice versa.
Alan Perlis
![Page 32: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/32.jpg)
XXXI the heisenberg requirement
h
the more stable a requirement is considered, the greater the
probability it is changed.
![Page 33: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/33.jpg)
XXXII the norman strange
attractor
h
the hardest part of design… is keeping features out.
Donald Norman
![Page 34: The Laws of Software Engineering in just Five Bits](https://reader034.vdocuments.net/reader034/viewer/2022042817/55a208fc1a28abe8788b4909/html5/thumbnails/34.jpg)
XXXII+I the divine equivalence
h
software and cathedrals both rely on the same process*
* first you build, then you pray.