Technical debt isn't technical - presented at NDC Oslo 2018.

1. TECHNICAL DEBT
ISN’T TECHNICAL
@EINARWH

2. 15.06.2018 2

3. 15.06.2018 3
WHAT IS
TECHNICAL DEBT?

4. 15.06.2018 4
TECHNICAL DEBT
AS A MEME

5. 15.06.2018 5

6. 15.06.2018 6
MEMETICS

7. 15.06.2018 7
SELF-REPLICATING
UNIT OF THOUGHT

8. 15.06.2018 8
COPIED FROM BRAIN
TO BRAIN

9. 15.06.2018 9
VIRUS OF THE MIND

10. 15.06.2018 10
WHAT MAKES A MEME
SUCCESSFUL?

11. 15.06.2018 11
SURVIVAL OF THE
FITTEST?

12. 15.06.2018 12
GREATEST
EXPLANATION
POWER?

13. 15.06.2018 13
MOST EFFECTIVE AT
REDUCING COGNITIVE
DISSONANCE?

14. 15.06.2018 14
THE BEST IDEAS
VS
THE IDEAS THAT
MAKE US FEEL BEST

15. 15.06.2018 15
WHAT IS
TECHNICAL DEBT?

16. 15.06.2018 16

17. 15.06.2018 17
SHIPPING FIRST TIME CODE IS
LIKE GOING INTO DEBT. A little
debt speeds development so long
as it is paid back promptly with a
rewrite... The danger occurs when
the debt is not repaid. Every
minute spent on not-quite-right
code counts as interest on that
debt. Entire engineering

18. 15.06.2018 18
WHAT MAKES TECHNICAL DEBT A
GOOD METAPHOR?

19. 15.06.2018 19
GIVES US LANGUAGE
TO TALK ABOUT SOMETHING
IMPORTANT!

20. 15.06.2018 20
PUTS QUALITY ON THE
AGENDA!

21. 15.06.2018 21
MAKES THE INVISIBLE
VISIBLE!

22. 15.06.2018 22
THANK YOU
WARD CUNNINGHAM!

23. 15.06.2018 23
WHAT MAKES TECHNICAL DEBT A
PROBLEMATIC METAPHOR?

24. 15.06.2018 24
MONETARY DEBT
IS QUANTIFIED

25. 15.06.2018 25
HOW MEASURABLE IS
TECHNICAL DEBT?

26. 15.06.2018 26
HOW BIG IS OUR
TECHNICAL DEBT?

27. 15.06.2018 27
ARE WE
TECHNICALLY SOLVENT?

28. 15.06.2018 28
CAN WE GO
TECHNICALLY BANKRUPT???

29. 15.06.2018 29
WHAT IS TECHNICAL
DEBT REALLY?

30. 15.06.2018 30
WHAT DOES TECHNICAL
DEBT LOOK LIKE?

31. 15.06.2018 31
”UGLY CODE”?

32. 15.06.2018 32

33. 15.06.2018 33
WHAT CAUSES
TECHNICAL DEBT?

34. 15.06.2018 34
WHAT MAKES THE
CODE UGLY?

35. 15.06.2018 35
LACK OF TIME?

36. 15.06.2018 36
MY PROJECT MANAGER
DOESN’T UNDERSTAND ME?

37. 15.06.2018 37
THE UX PEOPLE ARE
UNREALISTIC DREAMERS?

38. 15.06.2018 38
THE PREVIOUS DEVELOPER
WAS INCOMPETENT?

39. 15.06.2018 39
WHAT DOES TECHNICAL
DEBT LOOK LIKE?

40. 15.06.2018 40
HEAPS OF FLAGS,
BRANCHES AND
INDIRECTIONS

42. 15.06.2018 42
DIFFICULT TO DETERMINE
WHERE ONE THING ENDS
AND ANOTHER BEGINS

43. 15.06.2018 43
DIFFICULT TO ISOLATE CODE
RELATED TO A SINGLE
FEATURE

44. 15.06.2018 44
DIFFICULT TO PREDICT THE
EFFECT OF CHANGES

45. 15.06.2018 45
DIFFICULT TO REASON
ABOUT THE CODE

46. 15.06.2018 46
WHAT DOES THIS INDICATE?

47. 15.06.2018 47
THAT THE PRODUCT OWNER
DOESN’T UNDERSTAND
TECHNOLOGY?

48. 15.06.2018 48
THAT THE PREVIOUS
DEVELOPER USED THE WRONG
FRAMEWORK FOR DEPENDENCY
INJECTION?

49. 15.06.2018 49
THAT WE SHOULD
INTRODUCE MICRO
SERVICES?

50. 15.06.2018 50
THAT WE NEED
A NOSQL DATABASE?

51. THAT WE SHOULD GO
SERVERLESS?
15.06.2018 51

52. OR MOVE EVERYTHING TO
KUBERNETES?
15.06.2018 52

53. NO.
15.06.2018 53

54. 15.06.2018 54
( THAT MUCH WAS OBVIOUS. )

55. 15.06.2018 55
BUT IT’S ALSO OBVIOUS THAT
SOMETHING HAS GONE
FUNDAMENTALLY WRONG

56. 15.06.2018 56
SOMETHING HAS GONE WRONG
IN THE PROCESS OF
CAPTURING THE BUSINESS
DOMAIN IN SOFTWARE

57. 15.06.2018 57
SOMETHING HAS GONE WRONG
IN THE PROCESS OF
UNDERSTANDING THE BUSINESS
DOMAIN

58. 15.06.2018 58
SOMETHING HAS GONE WRONG
IN THE PROCESS OF
MAKING AND ENFORCING
DECISIONS

59. 15.06.2018 59
SOMETHING HAS GONE WRONG
IN THE PROCESS OF
FINDING A SUITABLE
REPRESENTATION OF THE
DOMAIN IN SOFTWARE

60. 15.06.2018 60
WE HAVE A WORD
FOR THIS PROCESS

61. 15.06.2018 61
MODELLING

62. 15.06.2018 62
MODELLING HAS FAILED

63. 15.06.2018 63
WHAT IS THE NAME OF THE
TOOL WE USE TO CONTAIN AND
CONQUER COMPLEXITY?

64. 15.06.2018 64
ABSTRACTION

65. 15.06.2018 65
WHAT IS THE NAME OF THE
TOOL WE USE TO CREATE AND
COMPOUND COMPLEXITY?

66. 15.06.2018 66
ABSTRACTION

67. 15.06.2018 67
MODELLING IS APPLYING
ABSTRACTION TO A
PROBLEM DOMAIN

68. 15.06.2018 68
MODELLING IS DEFINING
WHAT THE PROBLEM DOMAIN
IS

69. 15.06.2018 69
WORKING CONTINOUSLY TO
UNDERSTAND AND ARTICULATE
THE PROBLEM TO SOLVE IS NOT
BIG DESIGN UP FRONT

70. 15.06.2018 70
“You're wise to make the software
reflect your understanding as best
you can”

71. 15.06.2018 71
HOW CAN WE PAY OFF
TECHNICAL DEBT?

72. 15.06.2018 72
( EVERYBODY NOW )

73. 15.06.2018 73
REFACTORING!

74. 15.06.2018 74
WHICH REFACTORING FIXES
A TANGLED MESS OF WEAK
ABSTRACTIONS?

76. A rewrite will end up with
the same problems as the
original unless you close
the understanding gap.
— @sarahmei

77. 15.06.2018 77
NO REFACTORING
WITHOUT REMODELLING

78. 15.06.2018 78
ANYTHING ELSE IS
DEVELOPER HUBRIS

79. 15.06.2018 79
SOFTWARE
CRAFTSMAN
TO THE
RESCUE

80. 15.06.2018 80

81. 15.06.2018 81
SO-CALLED BEST PRACTICES
ARE NOT ENOUGH!

82. 15.06.2018 82
CLEAN CODE CAN NOT AND
WILL NOT SAVE A ROTTEN
MODEL!

83. 15.06.2018 83
YOU WILL WASTE
TIME AND MONEY!

84. 15.06.2018 84
FIX THE MODEL FIRST
THEN THE CODE

85. 15.06.2018 85
ARE WE DONE NOW?

86. 15.06.2018 86
HOW DO WE
FIX THE MODEL?

87. 15.06.2018 87
WHAT CAUSES
MODELLING DEBT?

88. 15.06.2018 88
( OMG HERE WE GO AGAIN! )

89. 15.06.2018 89
THE STORY OF EQUEST

90. 15.06.2018 90
A HORSE

91. 15.06.2018 91
A NEW HORSE

92. 15.06.2018 92
A SHORT, STRONG AND
STUBBORN HORSE

93. 15.06.2018 93
A HORSE?

94. 15.06.2018 94
A HORSE?

95. 15.06.2018 95
A HORSE?
+

96. 15.06.2018 96
A REGULAR HORSE

97. 15.06.2018 97
A TYPICAL HORSE

98. 15.06.2018 98
A TRUE HORSE

99. 15.06.2018 99
AN OLD-FASHIONED HORSE

100. 15.06.2018 100
A HORSE-HORSE

101. 15.06.2018 101
if (horse.IsShort && horse.IsStubborn) {
// Logic for the new horse case.
}
else
{
// Regular horse code here.
}

102. 15.06.2018 102
BUGS!

103. 15.06.2018 103
if (horse.IsShort &&
horse.IsStubborn &&
horse.Sound == Sound.HeeHaw)
{
// Logic for the new horse case.
}
else
{
// Regular horse code here.
}

104. 15.06.2018 104
A NEW NEW HORSE

105. 15.06.2018 105
THE KIND OF HORSE THAT
IS THE OFFSPRING OF A
REGULAR HORSE-HORSE
AND A SHORT AND STUBBORN
HORSE THAT GOES HEE-HAW

106. 15.06.2018 106
if (horse.IsShort &&
horse.IsStubborn &&
horse.Sound == Sound.HeeHaw) ||
(horse.Sire.IsShort &&
horse.Sire.IsStubborn &&
horse.Sire.Sound == Sound.HeeHaw) ||
(horse.Dam.IsShort &&
horse.Dam.IsStubborn &&
horse.Dam.Sound == Sound.HeeHaw))
{
// Logic for both the new horse
// and the new-new horse!
} else
{
// Really regular horse code here.
}

107. 15.06.2018 107
BUGS!

108. 15.06.2018 108
IS IT THE MOTHER
OR THE FATHER
THAT IS STUBBORN AND STRONG
AND GOES HEE-HAW?

109. 15.06.2018 109

110. 15.06.2018 110
A NEW NEW NEW HORSE

111. 15.06.2018 111

112. RECOMMENDED READING
WHAT, IF ANYTHING,
IS A ZEBRA?
SJ GOULD
15.06.2018 112

113. THERE IS NO TRUTH
TO BE UNCOVERED
15.06.2018 113

114. THERE ARE MORE OR LESS USEFUL
MODELS
15.06.2018 114

115. MODELLING IS AS MUCH ABOUT
DEFINING AS DISCOVERING
15.06.2018 115

116. THE STORY OF NRK TV
15.06.2018 116

117. WHAT, IF ANYTHING,
IS A TV SHOW?
15.06.2018 117

118. 15.06.2018 118
A TV SHOW

119. 15.06.2018 119
ANOTHER TV SHOW

120. 15.06.2018 120
YET ANOTHER TV SHOW

121. 15.06.2018 121
AND YET ANOTHER TV SHOW

122. 15.06.2018 122
A TV SHOW?

123. HOW MANY KINDS OF
TV SHOWS ARE THERE?
15.06.2018 123

124. WHICH CONCEPTS
SHOULD WE USE?
15.06.2018 124

125. HOW CAN WE ENABLE
OURSELVES TO TALK
PRECISELY?
15.06.2018 125

126. WHAT DO WE WANT TO
EXPRESS?
15.06.2018 126

127. MODELLING IS HARD!
15.06.2018 127

128. MODELLING IS HARD
FOR TWO REASONS
15.06.2018 128

129. 15.06.2018 129
#1
THE STUFF THAT IS
MODELLED

130. 15.06.2018 130
#2
THOSE DOING THE
MODELLING

131. WHY MODELLING IS HARD
#1
THE STUFF THAT IS MODELLED
15.06.2018 131

132. REALITY HAS NO INTEREST
IN BEING MODELLED
15.06.2018 132

133. REALITY IS NOT TIDY
AND ORGANIZED
15.06.2018 133

134. REALITY IS NOT EVEN
CONSISTENT
15.06.2018 134

135. REALITY IS MESSY AND
ORGANIC, SLIPS AWAY AND
EVOLVES
15.06.2018 135

136. WE ARE TRYING TO IMPOSE
STRUCTURE ON SOMETHING
UNSTRUCTURED
15.06.2018 136

137. RECOMMENDED READING
DATA AND REALITY
WILLIAM KENT
15.06.2018 137

138. IDENTITY
( WHAT IS ONE
THING? )
15.06.2018 138

139. EQUALITY
( WHEN ARE TWO THINGS
EQUAL? )
( WHEN ARE THEY THE SAME
THING? )15.06.2018 139

140. CHANGE
( WHEN DO TWO THINGS
BECOME DISTINCT? )
( WHEN HAS ONE THING
BECOME ANOTHER? )15.06.2018 140

141. CATEGORY
( WHICH CATEGORY DOES A
THING BELONG TO? )
( CAN A THING CHANGE
CATEGORY? )15.06.2018 141

142. RECOMMENDED READING
WOMEN, FIRE AND
DANGEROUS THINGS
GEORGE LAKOFF
15.06.2018 142

143. THE CLASSICAL THEORY
OF CATEGORIZATION IS
BASED ON PROPERTIES
15.06.2018 143

144. CLASSES IN PROGRAMMING
LANGUAGES LIKE
SIMULA AND C#
15.06.2018 144

145. NECESSARY AND
SUFFICIENT PROPERTIES
DETERMINE CATEGORY
MEMBERSHIP
15.06.2018 145

146. WHAT DOES A BIRD
LOOK LIKE?
15.06.2018 146

147. 15.06.2018 147

148. 15.06.2018 148

149. 15.06.2018 149

150. SOME MEMBERS OF A
CATEGORY ARE MORE
TYPICAL THAN OTHERS
15.06.2018 150

151. A SPARROW IS MORE
BIRDY THAN A PENGUIN
15.06.2018 151

152. A SPARROW IS MORE
BIRDY THAN A SHOEBILL
15.06.2018 152

153. A SPARROW IS PROBABLY THE
BIRDIEST BIRD THERE IS
15.06.2018 153

154. ELEANOR ROSCH
PROTOTYPE THEORY
15.06.2018 154

155. HOW UNTYPICAL IS
TOO UNTYPICAL?
15.06.2018 155

156. HOW UNEQUAL IS
TOO UNEQUAL?
15.06.2018 156

157. WHEN DOES A DONKEY
BECOME A DONKEY?
15.06.2018 157

158. IT DEPENDS!
15.06.2018 158

159. THE DONKEY DOESN’T CARE!
15.06.2018 159

160. WE PUT THINGS IN
CATEGORIES TO MAKE SENSE
OF REALITY
15.06.2018 160

161. GENERALIZATION IS A
HYPOTHESIS ABOUT
THE FUTURE
15.06.2018 161

162. BEWARE ARTIFICIAL
AD-HOC
GENERALIZATIONS!
15.06.2018 162

163. WHY MODELLING IS HARD #2
THOSE DOING THE
MODELLING
15.06.2018 163

164. WHO MAKES SOFTWARE?
15.06.2018 164

165. WHO OWNS
TECHNICAL DEBT?
15.06.2018 165

166. THE REST OF THE
ORGANIZATION WOULD LOVE
FOR TECHNICAL DEBT TO BE
THE PROBLEM OF THE IT
DEPARTMENT
15.06.2018 166

167. IF YOU REMAKE AWFUL
SOFTWARE FROM SCRATCH
WITHOUT CHANGING THE
CULTURE THAT CREATED IT
YOU’LL REMAKE AWFUL
SOFTWARE.
— @MALK_ZAMETH

168. CONWAY’S LAW
15.06.2018 168

169. RECOMMENDED READING
HOW DO COMMITTEES INVENT?
MEL CONWAY
15.06.2018 169

170. JUST BY ORGANIZING A TEAM
SOME DESIGN DECISIONS HAVE
ALREADY BEEN MADE
15.06.2018 170

171. HOW AGILE IS THE
ORGANIZATION?
15.06.2018 171

172. IS THE ORGANIZATION ABLE
TO MODIFY ITSELF TO SOLVE
THE TASK BETTER – DESIGN A
BETTER SYSTEM?
15.06.2018 172

173. CAN THE ORGANIZATION
DISSOLVE ITSELF, REFORM
AND CREATE A MORE
SUITABLE ORGANIZATION?
15.06.2018 173

174. CONWAY’S
HOMOMORPHISM
15.06.2018 174

175. IS THERE A RELATIONSHIP
BETWEEN THE STRUCTURE OF
AN ORGANIZATION AND THE
STRUCTURE OF THE SYSTEM
IT DESIGNS?
15.06.2018 175

176. YES.
15.06.2018 176

177. AN ORGANIZATION TENDS
TO PRODUCE SELF-
PORTRAITS IN THE
SYSTEMS IT CREATES
15.06.2018 177

178. INVERSE CONWAY MANEUVER
REORGANIZE TO DRIVE
ARCHITECTURAL CHANGE
15.06.2018 178

179. COROLLARY TO CONWAY’S
LAW:
IF YOU DESIGN A SYSTEM, BUT
YOU DIDN’T DESIGN THE
ORGANIZATION STRUCTURE,
YOU’RE NOT THE SYSTEM’S
DESIGNER.
— @MATHIASVERRAES

180. THE DIVIDE BETWEEN
BUSINESS AND IT IS
PROBLEMATIC
15.06.2018 180

181. SYSTEM ARCHITECTURE IS
ENTERPRISE ARCHITECTURE
AND VICE VERSA
15.06.2018 181

182. 15.06.2018 182

183. WE HAVE COME A LONG WAY
FROM UGLY CODE!
15.06.2018 183

184. WHY DO WE STILL TALK ABOUT
TECHNICAL DEBT?
15.06.2018 184

185. THE CONSEQUENCES ARE MADE
MANIFEST AND VISIBLE AT THE
TECHNICAL LEVEL
15.06.2018 185

186. DEVELOPERS LOOK FOR
TECHNICAL SOLUTIONS TO
SOFT PROBLEMS
15.06.2018 186

187. THE SOFT PROBLEMS ARE THE
HARD PROBLEMS
15.06.2018 187

188. TECHNICAL TASKS
ARE TEMPTING!
15.06.2018 188

189. THEY FIT OUR TRAINING
AND EXPERTISE
15.06.2018 189

190. THEY INVOLVE LITTLE IN
TERMS OF PSYCHOLOGY
AND POLITICS
15.06.2018 190

191. THEY RARELY LEAD
TO CONFLICT
15.06.2018 191

192. TECHNICAL WORK IS
PUZZLE SOLVING
15.06.2018 192

193. MODELLING WORK
REVEALS TENSIONS
15.06.2018 193

194. YOU MAY HAVE TO
REORGANIZE IN ORDER TO
BE ABLE TO REFACTOR
15.06.2018 194

195. WHAT MAKES A MEME
SUCCESSFUL?
15.06.2018 195

196. 15.06.2018 196
GREATEST
EXPLANATION
POWER?

197. 15.06.2018 197
MOST EFFECTIVE AT
REDUCING COGNITIVE
DISSONANCE?

198. 15.06.2018 198
THERE ARE
NO TECHNICAL SOLUTIONS
TO TECHNICAL DEBT

199. 15.06.2018 199
TECHNICAL DEBT ISN’T
TECHNICAL