Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
the laws of
faculty of engineering university of porto
Software Engineering
in just five bits
joão pascoal faria hugo sere...
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. ther...
IV
the archimedean principle
h
a software system built on top of a
weak architecture will sink due to
the weight of its o...
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 sof...
IX
the murphy approximation
h
all programs have errors*
* the number of errors (n) in a given program can be
approximated...
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 sof...
XII
the deadline amplification
h
the estimated time remaining to
finish any given project is a
monotonically increasing f...
XIII
the second zeno paradox
h
what remains to be done is not
enough to satisfy the customer*
*customer’s satisfaction is...
XIV
the non-acceptance
conservation principle
h
the x% that remains to be
implemented have (100-x)% of
importance to the ...
XV
the agile peculiarity
h
there’s always time to make more
changes until there’s no more
time to make changes*
* it’s al...
XVI
the social responsibility of a
software engineer
h
if the world ends in a catastrophic
scenario… who you gonna call?
...
XVII
the dijkstra observation
h
if debugging is the process of
removing software bugs, then
programming must be the
proce...
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
unde...
XX
the ninety-ninety rule
h
the first 90% of the code accounts
for the first 90% of the
development time. The remaining 1...
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...
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 recursio...
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...
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.
Upcoming SlideShare
Loading in …5
×

of

The Laws of Software Engineering in just Five Bits Slide 1 The Laws of Software Engineering in just Five Bits Slide 2 The Laws of Software Engineering in just Five Bits Slide 3 The Laws of Software Engineering in just Five Bits Slide 4 The Laws of Software Engineering in just Five Bits Slide 5 The Laws of Software Engineering in just Five Bits Slide 6 The Laws of Software Engineering in just Five Bits Slide 7 The Laws of Software Engineering in just Five Bits Slide 8 The Laws of Software Engineering in just Five Bits Slide 9 The Laws of Software Engineering in just Five Bits Slide 10 The Laws of Software Engineering in just Five Bits Slide 11 The Laws of Software Engineering in just Five Bits Slide 12 The Laws of Software Engineering in just Five Bits Slide 13 The Laws of Software Engineering in just Five Bits Slide 14 The Laws of Software Engineering in just Five Bits Slide 15 The Laws of Software Engineering in just Five Bits Slide 16 The Laws of Software Engineering in just Five Bits Slide 17 The Laws of Software Engineering in just Five Bits Slide 18 The Laws of Software Engineering in just Five Bits Slide 19 The Laws of Software Engineering in just Five Bits Slide 20 The Laws of Software Engineering in just Five Bits Slide 21 The Laws of Software Engineering in just Five Bits Slide 22 The Laws of Software Engineering in just Five Bits Slide 23 The Laws of Software Engineering in just Five Bits Slide 24 The Laws of Software Engineering in just Five Bits Slide 25 The Laws of Software Engineering in just Five Bits Slide 26 The Laws of Software Engineering in just Five Bits Slide 27 The Laws of Software Engineering in just Five Bits Slide 28 The Laws of Software Engineering in just Five Bits Slide 29 The Laws of Software Engineering in just Five Bits Slide 30 The Laws of Software Engineering in just Five Bits Slide 31 The Laws of Software Engineering in just Five Bits Slide 32 The Laws of Software Engineering in just Five Bits Slide 33 The Laws of Software Engineering in just Five Bits Slide 34
Upcoming SlideShare
As 32 Leis da Engenharia de Software
Next
Download to read offline and view in fullscreen.

38 Likes

Share

Download to read offline

The Laws of Software Engineering in just Five Bits

Download to read offline

Famous quotes (and then some not so famous), humoristically depicting the art of software engineering.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

The Laws of Software Engineering in just Five Bits

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

    Jul. 25, 2017
  • KaiRadewald1

    Jun. 28, 2017
  • kairadewald

    Jun. 28, 2017
  • SinanBUYRUK

    Feb. 4, 2016
  • mmdemirbas

    Dec. 6, 2015
  • imherprivatesuperman

    Sep. 12, 2015
  • CisseHalid

    Jul. 6, 2015
  • AliSinanBuyruk

    Jun. 21, 2015
  • NicolasKlein

    Jun. 15, 2015
  • Genzers

    May. 29, 2015
  • analog76

    Apr. 12, 2015
  • poudelrohit

    Mar. 15, 2015
  • DenizePimenta

    Mar. 13, 2015
  • lilou_13

    Feb. 27, 2015
  • MariusGmc

    Feb. 15, 2015
  • rajamohd2

    Feb. 14, 2015
  • jitukhandal

    Jan. 22, 2015
  • GuillaumeTollu

    Jan. 22, 2015
  • SaratChandraSista

    Jan. 19, 2015
  • nazeem.khan

    Jan. 16, 2015

Famous quotes (and then some not so famous), humoristically depicting the art of software engineering.

Views

Total views

10,787

On Slideshare

0

From embeds

0

Number of embeds

1,937

Actions

Downloads

200

Shares

0

Comments

0

Likes

38

×