My keynote at GOTO Berlin 2013

1. The Epistemology of Software
Engineering
Nathan Marz
@nathanmarz
1

2. My personal philosophies on software development

4. Agenda
1. Limits of human knowledge
2. Effect of the limits of knowledge on software development
3. Embracing those limits enables you to build better software

5. How do I know my software is correct?

6. How do I know a proposition is true?

7. Epistemology

8. How do I know my software is correct?
PREVIEW

9. You don’t

10. Your code is wrong

11. How do I know a proposition is true?
PREVIEW

12. You don’t

13. True knowledge is
unattainable

16. But wait... philosophy?

17. Strawman
Moral highground
Appeal to authority
Ad hominem attack
Appeal to emotion
Shotgun argumentation
Circular reasoning
Correlation vs causation
False dilemma
Equivocation
Argument to moderation
Burden of proof
Fallacies

19. Your code is wrong

20. Your code is literally wrong

21. Your code is wrong

23. Why do you believe your
code is correct?

24. Dependency 1
Dependency 2
Your code
Dependency 3

25. Dependency 4
Dependency 1
Dependency 5

26. Dependency 6
Dependency 7
Dependency 4
Dependency 8
Dependency 9

27. Dependency 3,000,000
Hardware

28. Electronics

29. Chemistry

30. Atomic physics

31. Quantum mechanics

32. I think I can safely say
that nobody understands
quantum mechanics.
Richard Feynman

33. Your code is wrong

34. ...
Your code

35. Infinite regress

36. Epistemological “solutions”
1. Infinitism
2. Foundationalism
3. Coherentism

37. Coherentism

38. Foundationalism
Axioms

39. René Descartes

40. Cogito ergo sum

41. I think,
therefore I am

42. Codito ergo sum

43. I code,
therefore I am

44. Cartesian foundationalism
1. Limited axioms
2. Knowledge through deduction

45. Cartesian programming
1. Axioms = rules of programming language
2. Programs = deductions from those axioms

49. -> OutOfMemoryException

50. -> Hallo welt!

51. All the software you’ve
used has had bugs in it

52. Including the software
you’ve written

57. Induction

58. f(0) and (f(n) → f(n+1))
∀n≥0, f(n)

59. Induction

62. <sidenote>

63. David Hume

64. “Why is inductive reasoning valid?”

65. </sidenote>

67. Skepticism

69. perfect code

70. value to users

71. “My software is correct”

72. “My software is
sometimes correct”

73. How do you minimize imperfection?

74. Storm’s “reportError” method

75. (Storm is a realtime computation
system, like Hadoop but for realtime)

76. Storm architecture

77. Storm architecture
Master node (similar to Hadoop JobTracker)

78. Storm architecture
Used for cluster coordination

79. Storm architecture
Run worker processes

80. Storm’s “reportError” method

81. Used to show errors in the Storm UI

82. Error info is stored in Zookeeper

83. What happens when a user deploys code like this?

84. Denial-of-service on Zookeeper
and cluster goes down

85. Irrelevant!
Designed input space
Robust!
Failures!
Bad performance!
Security holes!
Actual input space

86. Implement self-throttling to
avoid overloading Zookeeper

87. Robust!
Designed input space
Actual input space

88. Robust!
Designed input space
Actual input space

89. Epistemology

90. Trth
Trut
Truh
Tuth
Tru

91. Foundation of modern science

92. Newton’s laws of motion
1. When viewed in an inertial reference frame,
an object either is at rest or moves at a constant
velocity, unless acted upon by an external force.
2. The acceleration of a body is directly proportional to,
and in the same direction as, the net force acting on the
body, and inversely proportional to its mass. Thus, F = ma,
where F is the net force acting on the object, m is the mass
of the object and a is the acceleration of the object.
3. When one body exerts a force on a second body, the
second body simultaneously exerts a force equal in
magnitude and opposite in direction to that of the
first body.

93. Orbit of Mercury problem
Cambridge, we have a problem...

94. Einstein’s theory of relativity
Sorry, Newton, you’ve
been PWNED:

95. limit approximation (truth) = truth
n
n→∞

96. Science algorithm
1. Make observations
2. Find theories consistent with those observations
3. Falsify theories by making more observations

97. Foundationalism
+
Coherentism

98. Empiricism

99. John Locke

106. Occam’s Razor

107. Software
Use cases

108. Software gets messy

109. Refactoring

110. Robust!
Designed input space
Actual input space

111. Robust!
Designed input space
Actual input space

113. TESTING

116. Unit testing
Load testing
Stress testing
Fuzz testing

117. TDD?

118. Review
1. Cannot perfectly reason about software
•
Infinite regress problem
•
Deduction is fundamentally flawed
•
Evidence shows programmers are not good at deductive reasoning
2. Best you can do is minimize wrongness
•
Truth can only be approximate
•
Observe/theorize/falsify cycle minimizes wrongness over time
•
Testing = empiricism applied to software development
•
Make programs less wrong by testing more

119. Does any of this matter?

120. YES

121. Embrace “your code is wrong”
to design better software

124. Redundancy
Fault-tolerance
> Perfection

125. An example

126. Learning from Hadoop
Job
Jobtracker
Job
Job

127. Learning from Hadoop
Job
Jobtracker
Job
Job

128. Learning from Hadoop
Job
Jobtracker
Job
Job

129. Your code is wrong

130. So your processes will crash

131. Storm’s daemons are
process fault-tolerant

132. Storm
Topology
Nimbus
Topology
Topology

133. Storm
Topology
Nimbus
Topology
Topology

134. Storm
Topology
Nimbus
Topology
Topology

135. Storm
Topology
Nimbus
Topology
Topology

136. Storm
Topology
Nimbus
Topology
Topology

137. Robust!
Designed input space
Actual input space

138. Robust!
Designed input space
Actual input space

139. Reasoning is fundamentally hard

140. So program in ways that require
less of it

143. Pure function

144. Mutability is hard to reason about

145. Minimize state mutation

146. Functional programming

147. Clojure

148. skepticism(skepticism)

149. ?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
perfect software
?
?
?
?
?
?

150. Thank you