1
00:00:00,000 --> 00:00:15,720
*34c3 preroll music*

2
00:00:15,720 --> 00:00:20,940
Herald: Der Fefe hatte mich gebeten,
mich kurz zu halten, weil, er hat Angst,

3
00:00:20,940 --> 00:00:26,740
dass der Talk nicht in die 30 Minuten passt.
Von daher gebe ich jetzt mal Gas und

4
00:00:26,740 --> 00:00:29,909
sage: „Antipatterns und Missverständnisse
in der Software-Entwicklung“!

5
00:00:29,909 --> 00:00:34,049
Und wie sagte jemand gestern?
„Ach Fefe! Das ist doch der mit der Kolumne

6
00:00:34,049 --> 00:00:37,870
beim ehemaligen Nachrichtenmagazin!“
Here we go!

7
00:00:37,870 --> 00:00:47,040
*Applaus*

8
00:00:47,040 --> 00:00:50,691
Fefe: Hallo hallo. Hallo hallo. Ja, ja
vielen Dank, dass ihr so zahlreich

9
00:00:50,691 --> 00:00:53,350
erschienen seid. Ein bisschen zahlreicher,
als ich gedacht habe. Nächstes Mal mache

10
00:00:53,350 --> 00:00:59,260
ich doch lieber parallel zu Minkorrekt
wieder. Es geht um Antipatterns.

11
00:00:59,260 --> 00:01:04,170
Antipatterns sind Sachen, die man macht,
die man häufig macht, die populäre

12
00:01:04,170 --> 00:01:07,820
Maßnahmen sind, um ein Problem zu lösen,
die dann aber entweder gar nicht

13
00:01:07,820 --> 00:01:13,680
funktionieren oder nach hinten losgehen.
Und ich habe mir gedacht, beim Congress

14
00:01:13,680 --> 00:01:17,840
gibt es immer so schöne Streitereien um
das Motto. Da mache ich auch mal ein Motto.

15
00:01:17,840 --> 00:01:20,350
Und das hier ist so ein Motto, was
ich sehr profunde finde, und wo ihr

16
00:01:20,350 --> 00:01:25,850
hoffentlich im Laufe des Vortrags sehen
werdet, warum das das Motto ist. Ja, „wer

17
00:01:25,850 --> 00:01:31,530
lesen kann, aber es nicht tut, hat keinen
Vorteil dem gegenüber, der das nicht kann“.

18
00:01:31,530 --> 00:01:36,330
Die Struktur des Vortrags…
*Applaus*

19
00:01:36,330 --> 00:01:41,720
Die Struktur des Vortrags will ich an
einem Beispiel kurz umreißen.

20
00:01:41,720 --> 00:01:45,640
Es geht immer damit los,
dass wir ein Problem haben.

21
00:01:45,640 --> 00:01:50,380
Dann geht immer Seal Team 6
los und hackt irgendwas.

22
00:01:50,380 --> 00:01:53,280
Also denkt euch hier ein Team von
Spezialexperten. Ja ich will jetzt nicht

23
00:01:53,280 --> 00:01:58,190
die Seals beleidigen, bestimmt auch alles
nette Leute. Und dann kommt eine Umsetzung,

24
00:01:58,190 --> 00:02:02,780
da geht es meistens in die Hose.
Und dann haben wir einen Effekt, und

25
00:02:02,780 --> 00:02:08,390
hoffentlich, hoffentlich eine Erkenntnis
gewonnen. Ich habe mir gedacht, wir

26
00:02:08,390 --> 00:02:11,840
versuchen mal so eine interaktive
Komponente. Und zwar wenn man sich so

27
00:02:11,840 --> 00:02:15,920
Übertragungen aus dem britischen Parlament
ansieht, dann gibt es immer so ein

28
00:02:15,920 --> 00:02:19,372
Gemurmel, wenn die Leute zustimmen. Und
ich dachte mir, wenn ich sage, „Hebt mal

29
00:02:19,372 --> 00:02:23,190
den Arm, wenn euch das mal passiert ist“,
dann haben die Leute vielleicht Angst, auf

30
00:02:23,190 --> 00:02:26,690
dem Stream zu landen und sich zu outen.
Deswegen dachte ich, wir murmeln mal. Also

31
00:02:26,690 --> 00:02:30,020
wenn einer von euch sich bei einem Muster
wiedererkennt, könnt ihr mal versuchen.

32
00:02:30,020 --> 00:02:34,210
Wir gucken mal, ob das klappt. Ja,
vielleicht hört man das dann. Okay.

33
00:02:34,210 --> 00:02:38,690
Also, erstes Problem. Dieses Bild, ich
möchte das gleich dazusagen,

34
00:02:38,690 --> 00:02:44,680
*Lachen*
ist mir gespendet worden.

35
00:02:44,680 --> 00:02:48,339
Ich liefere hier keine Kunden ans Messer,
und es geht nur um Anekdoten.

36
00:02:48,339 --> 00:02:52,599
Also wer sich glaubt, wiederzuerkennen,
liegt wahrscheinlich falsch.

37
00:02:52,599 --> 00:02:56,040
So, das ist ein typisches Problem
in der Software-Entwicklung:

38
00:02:56,040 --> 00:03:00,010
die Versionierung von und die Backups
von alten Versionen aufzuheben.

39
00:03:00,010 --> 00:03:05,220
Das ist hier, ich hoffe, ihr habt das gesehen
oben in der Ecke, das ist ein USB-Stick.

40
00:03:05,220 --> 00:03:07,950
Und die typische Idee ist: Wir machen
jetzt mal ein Versionierungssystem!

41
00:03:07,950 --> 00:03:11,800
Und das ist eine gute Idee. Die
Umsetzung ist dann gewöhnlich:

42
00:03:11,800 --> 00:03:14,820
der, der gerade ein akutes
Problem hat, bastelt schnell was,

43
00:03:14,820 --> 00:03:18,550
und dann kriegt man so ein Git. Und Git
ist eigentlich gut, aber man hat halt

44
00:03:18,550 --> 00:03:22,960
nicht nur Git, sondern man hat dann noch
so ein paar andere Versionierungssysteme,

45
00:03:22,960 --> 00:03:27,129
und da gehen dann die Probleme los. Ja
also, ich habe mal einen, ich habe mal so

46
00:03:27,129 --> 00:03:30,070
einen Kunden gehabt, die meinten: „Ist im
Git“, und dann meinte der Typ daneben:

47
00:03:30,070 --> 00:03:33,009
„Ja, musst noch sagen, in welchem“.
Also das kommt vor.

48
00:03:33,009 --> 00:03:36,379
*Lachen*
Ein anderer Effekt, den man häufig

49
00:03:36,379 --> 00:03:40,770
sieht, ist, dass jeder überall einchecken
darf. Und das führt dann zu so Sachen wie:

50
00:03:40,770 --> 00:03:45,540
man meldet als Bug so was wie: „In dem
Image sind aber noch set-UID-Binaries“

51
00:03:45,540 --> 00:03:48,540
oder sowas. Und dann machen die die alle
weg, und dann installiert man die nächste

52
00:03:48,540 --> 00:03:52,040
Version, und dann sind wieder welche, und
dann sagt der Typ: „Ja, ich habe die zwar

53
00:03:52,040 --> 00:03:55,850
alle weg gemacht, aber hat halt ein
Developer wieder rein gemacht“.

54
00:03:55,850 --> 00:04:00,270
Also Versionierung reicht noch nicht.
Da muss man noch mehr machen.

55
00:04:00,270 --> 00:04:04,470
Überhaupt die Idee, dass Leute Binaries
einchecken, ist eine ganz schlechte.

56
00:04:04,470 --> 00:04:07,010
Das findet man immer wieder.
Ich rede jetzt hier nicht von png

57
00:04:07,010 --> 00:04:11,140
oder irgendwie ein mpeg von einer Webseite
oder sowas, sondern so eine Library oder

58
00:04:11,140 --> 00:04:14,750
ein Executable. Das sollte man
eigentlich nicht tun.

59
00:04:14,750 --> 00:04:17,790
Es gibt ganz wenige Ausnahmen.
Wenn ihr eine von den Ausnahmen habt,

60
00:04:17,790 --> 00:04:21,400
wisst ihr es, und ansonsten
macht es nicht!

61
00:04:21,400 --> 00:04:23,790
Das hier ist jetzt natürlich überspitzt,
aber so ähnlich habe ich das schon

62
00:04:23,790 --> 00:04:27,410
mal gesehen, dass Leute verschiedene
Versionen einchecken, aber nicht

63
00:04:27,410 --> 00:04:31,210
verstanden haben, was eigentlich die Aufgabe
von so einem Versionierungssystem ist.

64
00:04:31,210 --> 00:04:36,910
Das ist auch nicht gut, macht das nicht!

65
00:04:36,910 --> 00:04:41,330
Ich habe dann immer so einen Ratschlag
am Ende von den jeweiligen Antipatterns.

66
00:04:41,330 --> 00:04:44,710
Und mein Ratschlag für Versionierungssysteme
ist: Git ist schon in Ordnung.

67
00:04:44,710 --> 00:04:48,240
Ich bin mir der Ironie bewusst, dass meine
eigene Software im Moment als CVS

68
00:04:48,240 --> 00:04:51,490
im Internet ist. Das hat historische Gründe!

69
00:04:51,490 --> 00:04:57,852
*Lachen und Applaus*

70
00:04:57,852 --> 00:05:02,562
Patches hält man am besten klein, damit
man sie einzeln anfassen kann,

71
00:05:02,562 --> 00:05:05,080
wenn sie nicht sauber applyen.
Das ist ein Riesenproblem, wenn jemand

72
00:05:05,080 --> 00:05:07,710
so einen Megabyte-Patch abliefert.
Deswegen macht das nicht.

73
00:05:07,710 --> 00:05:12,170
Wenn ihr größere Sachen vorbereiten müsst,
dann macht das nicht als einen großen

74
00:05:12,170 --> 00:05:15,790
Patch, sondern nehmt einen eigenen Branch
dafür. So ein Versionierungssystem will

75
00:05:15,790 --> 00:05:20,960
euch helfen. Also beschäftigt euch mit den
Features, die sie euch bieten.

76
00:05:20,960 --> 00:05:24,660
Wenn man Annahmen hat, über, welche APIs
verfügbar sind, oder welche Versionen von

77
00:05:24,660 --> 00:05:29,190
Komponenten drin sein sollen, sollte man
das im Build in einem Skript checken.

78
00:05:29,190 --> 00:05:32,709
Und nicht erst anfangen zu bauen, und nach
zwei Stunden abbrechen, weil irgendwas

79
00:05:32,709 --> 00:05:36,210
nicht geklappt hat. Sowas möglichst
vorher testen, damit es schnell failt,

80
00:05:36,210 --> 00:05:39,280
damit man schnell reagieren kann.

81
00:05:39,280 --> 00:05:42,660
Es gibt häufig so die Idee in Firmen, dass
man verschiedene Abteilungen hat und jede

82
00:05:42,660 --> 00:05:47,470
hat ihr eigenes Versionierungssystem oder
ihr eigenes Repository. Und das kann

83
00:05:47,470 --> 00:05:52,159
funktionieren, aber es ist sehr selten, ja?
Häufig, der… der…

84
00:05:52,159 --> 00:05:55,980
die Sache, die stimmen muss, damit es
klappt, ist, dass die APIs stabil sind.

85
00:05:55,980 --> 00:05:59,200
Und erfahrungsgemäß glauben alle, dass
ihre APIs stabil bleiben werden, und

86
00:05:59,200 --> 00:06:04,820
sie sind es dann aber nie. Also wenn ihr
das vermeiden könnt, macht das nicht.

87
00:06:04,820 --> 00:06:07,820
So, das nächste Problem ist: die Bugs
fallen immer unter den Tisch, werden

88
00:06:07,820 --> 00:06:11,450
vergessen, gefixt zu werden. Und die
offensichtliche Lösung ist:

89
00:06:11,450 --> 00:06:15,910
wir machen so einen Bugtracker.
Umsetzung ist natürlich wie immer Seal

90
00:06:15,910 --> 00:06:20,840
Team 6. Und der Effekt, der sich ganz
schnell einstellt, ist, dass man merkt,

91
00:06:20,840 --> 00:06:25,660
man hat ganz viele Bugs. Und das
ist dann gleich das nächste Problem:

92
00:06:25,660 --> 00:06:29,470
wir haben so viele Bugs,
was machen wir jetzt?

93
00:06:29,470 --> 00:06:32,609
Eine Sache, die ich inzwischen als
Antipattern sehe, ist: Priorisieren von

94
00:06:32,609 --> 00:06:37,510
Bugs. Ja, so eine übliche Umsetzung ist:
man hat sowas wie „Severity: Blocker“

95
00:06:37,510 --> 00:06:41,760
oder das ist ein Security-Bug – das soll
hier eine Checkbox sein. Und der Effekt

96
00:06:41,760 --> 00:06:45,670
davon ist, dass alle anderen Bugs liegen
bleiben. Das kann man immer und immer

97
00:06:45,670 --> 00:06:49,830
wieder beobachten. Also die… der
eigentliche… was ich so beobachte, der,

98
00:06:49,830 --> 00:06:52,759
der Effekt, der die meisten Bugs tötet,
ist, wenn eine Komponente einfach

99
00:06:52,759 --> 00:06:55,930
abgeschafft wird. Und dann kann man
alles schließen in der Komponente.

100
00:06:55,930 --> 00:06:59,550
Dass tatsächlich mal sowas
weggeht, gibt es nicht.

101
00:06:59,550 --> 00:07:04,240
*Applaus*
Es gibt ein schönes Wort dafür, wo mir

102
00:07:04,240 --> 00:07:09,419
jetzt die Übersetzungsteams bisschen leid
tun, nämlich Bug-Welle, im Sinne von einer

103
00:07:09,419 --> 00:07:14,040
Bugwelle vor so einem Tanker. Ich versuche
das gerade mal zu etablieren, als Begriff.

104
00:07:14,040 --> 00:07:18,080
Ich finde den nämlich sehr schön. So, also
jetzt haben wir ganz viele offene Bugs,

105
00:07:18,080 --> 00:07:22,300
was machen wir denn jetzt? Nächstes
Problem. Und eine Idee, die häufig kommt,

106
00:07:22,300 --> 00:07:27,320
und die auch erstmal total super klingt,
ist, dass man bug-freien Code belohnt.

107
00:07:27,320 --> 00:07:31,389
Und zwar am besten mit so einem Bonus, am
besten in Geld. Wenn euer Team keine

108
00:07:31,389 --> 00:07:36,780
offenen Bugs hat, dann werdet ihr belohnt.
Und das führt eben dazu, das ist mir mal

109
00:07:36,780 --> 00:07:40,849
passiert, dass ich so eine Mail gekriegt
habe von einem Typ, wo ich ein paar Bugs

110
00:07:40,849 --> 00:07:45,290
gefilet habe, und der kommt und meint: „Du
Arschloch, jetzt ist mein Bonus weg. Ich

111
00:07:45,290 --> 00:07:50,560
kann meine Hypothek nicht abzahlen!“
Und da wusste ich dann auch erstmal nicht

112
00:07:50,560 --> 00:07:55,319
direkt, was ich dem sagen soll. Der hat
das dann selbst gelöst, indem er alle Bugs

113
00:07:55,319 --> 00:07:59,920
zugemacht hat und zwar mit NOTABUG.
*Lachen*

114
00:07:59,920 --> 00:08:02,610
Hat mir natürlich versprochen, dass die
trotzdem alle gefixt werden. Aber das

115
00:08:02,610 --> 00:08:07,030
könnt ihr euch ja vorstellen, wie gut das
klappt. Also sowas ist sehr… ist sehr mit

116
00:08:07,030 --> 00:08:11,539
Vorsicht zu genießen. Reward- und
Incentives-Sachen am besten nicht mit

117
00:08:11,539 --> 00:08:16,809
Geld. Es gibt auch ein Anti-Antipattern
dazu. Nämlich habe ich mal erlebt, dass

118
00:08:16,809 --> 00:08:20,990
jemand alle Bugs im Code gefixed hat, aber
im Bugtracker waren die noch offen. Und

119
00:08:20,990 --> 00:08:23,920
dann habe ich nicht verstanden, bin
hingegangen, und dann hat er mir erklärt:

120
00:08:23,920 --> 00:08:26,330
„Ja, die brauchen mich ja nicht mehr,
wenn die Bugs zu sind.“

121
00:08:26,330 --> 00:08:29,090
*Lachen und Applaus*
Der hat halt gesehen, hat halt gesehen, um

122
00:08:29,090 --> 00:08:34,629
ihn rum die Kollegen sind alle nach Indien
abgeschoben worden, die Projekte, und

123
00:08:34,629 --> 00:08:37,779
hat sich gedacht: „Na, die lass ich lieber
offen, die Bugs, dann werde ich hier noch

124
00:08:37,779 --> 00:08:41,639
ein paar Monate bezahlt.“ Das hat mir
echt, das fand ich echt atemberaubend.

125
00:08:41,639 --> 00:08:45,369
Da habe ich so ein paar Tage schlecht
geschlafen. Weil das ist ja schon… was

126
00:08:45,369 --> 00:08:49,040
für ein Selbstbild hat der denn, wenn er
glaubt, irgendwie diese, diese Einträge im

127
00:08:49,040 --> 00:08:53,630
Bugtracker halten ihn da am Leben? Ganz
furchtbar. Aber das gibt es in kleineren

128
00:08:53,630 --> 00:09:00,040
Ausmaßen häufiger, dass Leute Bugs offen
lassen, weil sie wissen: wenn die Bugs weg

129
00:09:00,040 --> 00:09:05,050
sind, dann kommt der Chef mit der nächsten
To-Do-Liste. Und der einzige Weg, mal eine

130
00:09:05,050 --> 00:09:08,830
Woche Luft zu haben, ist einfach, die Bugs
nicht zu fixen. Das gibt es häufiger,

131
00:09:08,830 --> 00:09:12,429
achtet mal darauf in eurer Firma, ob
ihr das auch sehen könnt. Ich würde fast

132
00:09:12,429 --> 00:09:18,599
wetten: ja. Das ist ein häufiges Pattern.
Das ist auch ein Klassiker hier. Man hat

133
00:09:18,599 --> 00:09:22,470
ein tolles Projekt, und das ist wunderbar,
aber es funktioniert nur auf dem Rechner

134
00:09:22,470 --> 00:09:26,889
vom Entwickler. Und die Idee ist: man hat
jetzt einen Build-Server, ja? Wir haben

135
00:09:26,889 --> 00:09:29,779
jetzt einen Build-Server, da wird
gebaut, das ist eine neutrale Umgebung,

136
00:09:29,779 --> 00:09:33,709
alles super. Seal Team 6 bastelt kurz
was, und das sieht auch echt geil aus, ja?

137
00:09:33,709 --> 00:09:38,269
Hier, so Drohnen-assistierte
Baugeschichten. Aber übliche Sachen, die

138
00:09:38,269 --> 00:09:42,540
halt fehlschlagen, ist, dass dieser Build-
Server von dem Team ist, und baut halt den

139
00:09:42,540 --> 00:09:47,160
Code von dem Team. Und die anderen Sachen
werden aus irgendwelchen antiken Snapshots

140
00:09:47,160 --> 00:09:50,939
von anderen Leuten reingezogen. Oder was
ich auch mal gesehen habe: dass Libraries

141
00:09:50,939 --> 00:09:56,019
dann so per SMB da reingelinkt werden.
Und das ist natürlich totale Scheiße, ja?

142
00:09:56,019 --> 00:10:01,719
Aber das passiert, so was passiert. Eine
häufige Sache, die man auch sieht, ist,

143
00:10:01,719 --> 00:10:04,760
dass man so einen Build-Server hat, aber
da muss dann jemand hinlaufen und so

144
00:10:04,760 --> 00:10:09,339
„Build“ klicken. Und das ist auch nicht
schlau. Ich habe hier mal versucht, ein

145
00:10:09,339 --> 00:10:16,129
Bild herauszusuchen. Die Idee beim
Build-Server ist es, dass der am besten

146
00:10:16,129 --> 00:10:20,669
automatisiert baut, und zwar mindestens
einmal täglich. So, das habe ich auch

147
00:10:20,669 --> 00:10:22,879
schon erlebt: der Build ist
fehlgeschlagen, und dann hat der

148
00:10:22,879 --> 00:10:25,749
Entwickler eben auf dem Build-Server
angefangen, irgendwelche Dateien zu

149
00:10:25,749 --> 00:10:31,470
editieren. Das ist jetzt gerade im
Wachstum von Devops ein Problem, was wir

150
00:10:31,470 --> 00:10:35,249
häufiger sehen werden, glaube ich. Das
macht natürlich den Vorteil vom Build-

151
00:10:35,249 --> 00:10:39,109
Server komplett kaputt, ja? Weil, dann habe
ich wieder den Effekt, das ist ja der

152
00:10:39,109 --> 00:10:42,639
Rechner vom Developer, aber es ist halt nicht
mehr der unter seinem Tisch, sondern in

153
00:10:42,639 --> 00:10:47,289
dem Rack da hinten, wo „Build-Server“
dransteht. So, ich hoffe, dass wir demnächst

154
00:10:47,289 --> 00:10:50,239
ein Debian haben werden, was diese
Namenskonvention übernimmt.

155
00:10:50,239 --> 00:10:53,750
*Gelächter*
Das sieht man auch häufig, ja, nicht nur

156
00:10:53,750 --> 00:10:56,529
auf Build-Servern, sondern das wird halt
irgendwann aufgesetzt und danach bleibt

157
00:10:56,529 --> 00:11:00,170
das halt so. Und das hält das ganze
Projekt zurück, weil dann irgendwelche

158
00:11:00,170 --> 00:11:04,259
Software-Versionen da drauf sind. So übliche
Sachen sind irgendwie eine SSL-Library,

159
00:11:04,259 --> 00:11:09,040
die kein aktuelles TLS 1.2 kann. Und das
werden wir mit 1.3 demnächst wieder haben,

160
00:11:09,040 --> 00:11:12,919
das Problem. Oder irgendwie ein uraltes
C++, und dann können die Leute die neuen

161
00:11:12,919 --> 00:11:16,479
Features nicht benutzen. Also das ist
alles ganz furchtbar. Will das mal hier

162
00:11:16,479 --> 00:11:20,639
mit so einem schönen Müllhaufen
illustrieren. Der Grund, warum man einen

163
00:11:20,639 --> 00:11:25,190
Build-Server hat, ist, dass man täglich
bauen kann, automatisiert, ohne dass da

164
00:11:25,190 --> 00:11:29,879
jemand hingehen muss, und ohne dass jemand
hingehen kann, um irgendwas zu fixen. Da

165
00:11:29,879 --> 00:11:33,979
gibt es keine Interaktion außer: „Bau mal
diese Version“, ja? Der Build soll

166
00:11:33,979 --> 00:11:37,599
deterministisch sein. Das ist leider
unabhängig vom Build-Server, muss ich euch

167
00:11:37,599 --> 00:11:41,109
erzählen. Es gibt tatsächlich Build-
Prozesse, da fällt jedesmal ein anderes

168
00:11:41,109 --> 00:11:44,600
Binary raus, auch wenn man keine neue
Version ausgecheckt hat, weil irgendwie

169
00:11:44,600 --> 00:11:48,569
parallel gebaut wird und irgendwelche
Dateien, die gebraucht werden, werden

170
00:11:48,569 --> 00:11:52,209
asynchron von anderen Teilen aus dem
Parallel-Build erzeugt. Und wenn man Glück

171
00:11:52,209 --> 00:11:56,299
hat, kommt die richtige an. Und wenn man
Pech hat, halt nicht. Also das muss man

172
00:11:56,299 --> 00:12:00,959
fixen. Das ist Arbeit. Und es wäre mir
sehr lieb, dass so Open-Source-Entwickler

173
00:12:00,959 --> 00:12:06,719
auch alle dafür sorgen, dass ihre Projekte
mit beliebiger Parallelität baubar sind.

174
00:12:06,719 --> 00:12:09,819
Der nächste Grund für Build-Server
ist Agilität.

175
00:12:09,819 --> 00:12:12,179
*Applaus*
Ja? Wenn ich irgendwas kaputtgemacht habe,

176
00:12:12,179 --> 00:12:15,579
dann soll keine Panik ausbrechen, sondern
dann sage ich „Rollback“ und bau halt die

177
00:12:15,579 --> 00:12:19,349
Version von vorhin nochmal, die
funktioniert hat. Wenn das nicht ein

178
00:12:19,349 --> 00:12:23,690
Knopfdruck ist, dann könnt ihr den Build-
Server auch wegschmeißen. Und natürlich

179
00:12:23,690 --> 00:12:27,960
möchte man möglichst schnell mitkriegen,
wenn jemand was eingecheckt hat, was den

180
00:12:27,960 --> 00:12:32,419
Build bricht. Aber nicht sanktionieren!
Ich habe mal so eine Firma erlebt, die hat

181
00:12:32,419 --> 00:12:35,849
dann so ein Britney-Spears-T-Shirt gehabt,
und das musste der Typ tragen, der den

182
00:12:35,849 --> 00:12:38,489
letzten, zum letzten Mal den Build
gebrochen hat.

183
00:12:38,489 --> 00:12:43,720
*Lachen und Applaus*
Macht das nicht. Das hat gut funktioniert,

184
00:12:43,720 --> 00:12:46,410
bis sie so einen Britney-Spears-Fan als
Angestellten hatten.

185
00:12:46,410 --> 00:12:52,160
*Lachen*
Ja. So, also das nächste Problem: ich habe

186
00:12:52,160 --> 00:12:55,079
jetzt zwar einen Build-Server, und der
baut das zwar unabhängig vom

187
00:12:55,079 --> 00:12:58,460
Entwicklerrechner, aber das Binary
funktioniert nur auf dem Rechner vom

188
00:12:58,460 --> 00:13:03,859
Entwickler. Ist ein subtil anderes
Problem, aber verwandt. Und das löst man

189
00:13:03,859 --> 00:13:07,030
heute mit Docker, ist ja klar!
*Applaus*

190
00:13:07,030 --> 00:13:10,809
Und Docker ist im Prinzip keine schlechte
Idee. Man darf halt nicht Seal Team 6

191
00:13:10,809 --> 00:13:14,609
basteln lassen. Denn da kommen
dann so Effekte wie: ich lutsche mir

192
00:13:14,609 --> 00:13:18,919
irgendwelche Images von irgendwo aus dem
Internet rein. Klassiker sind so Ramses-

193
00:13:18,919 --> 00:13:24,919
der-Zweite-Debian und MySQL drei Punkt
irgendwas von neunzehnhundert-äh.

194
00:13:24,919 --> 00:13:29,569
So, dafür ist Docker nicht da. Docker ist
gerade dafür da, dass das agil änderbar

195
00:13:29,569 --> 00:13:33,139
ist. Und wenn ihr das nicht macht, dann
ist es, als wenn ihr nicht lest. Könnt ihr

196
00:13:33,139 --> 00:13:37,059
euch das gleich sparen. Also ich habe hier
mal Frankenstein als Illustration

197
00:13:37,059 --> 00:13:41,039
gebracht. Das bringt nichts. Dann habt ihr
so ein Schrott-Projekt am Ende. Ich sehe

198
00:13:41,039 --> 00:13:44,409
das häufig in der Industrie, dass die
Leute alle Nachteile mitnehmen, aber die

199
00:13:44,409 --> 00:13:49,279
Vorteile gezielt stehen lassen.
*Lachen und Applaus*

200
00:13:49,279 --> 00:13:52,880
Häufig gerade bei so Build-Systemen und
Docker ist, dass man die Komponenten in

201
00:13:52,880 --> 00:13:56,209
irgendwelchen statischen Versionen hart-
codet, die halt aktuell waren, als es

202
00:13:56,209 --> 00:14:01,749
aufgesetzt wurde, und danach nicht mehr
geupdatet werden, ja? Also ich habe in den

203
00:14:01,749 --> 00:14:04,819
letzten Jahren immer mehr Leute mit
Build-Servern gesehen, die alles

204
00:14:04,819 --> 00:14:08,789
automatisiert bauen. Und alle Dateien
im Image haben so denselben Time-

205
00:14:08,789 --> 00:14:12,629
Stamp grob. Also man sieht, dass es alles
frisch gebaut wurde, aber es sind trotzdem

206
00:14:12,629 --> 00:14:18,399
Versionen von 2004. Das ist sehr häufig,
achtet darauf bei euch, ja? Und wenn ein

207
00:14:18,399 --> 00:14:22,829
Zulieferer euch Kram gibt, der vom
Build-Server kommt mit alten Versionen,

208
00:14:22,829 --> 00:14:27,029
dann weist ihn darauf hin. Negatives
Feedback. Das ist sonst wie so ein

209
00:14:27,029 --> 00:14:34,850
Rollator: bremst nur. Container hat man
für automatisiertes Deployment in

210
00:14:34,850 --> 00:14:39,459
deterministischem Zustand. Das ist eine
Sache, die haben fast alle verstanden.

211
00:14:39,459 --> 00:14:43,050
Aber was nicht so verstanden wird, ist
dieser, der Rollback ist eben auch

212
00:14:43,050 --> 00:14:47,239
trivial, wenn man das mit so einem Docker-
System baut. Dann klicke ich halt „Mach mal

213
00:14:47,239 --> 00:14:50,729
die alte Version“ und dann fällt das Image
der alten Version raus. Das ist ein

214
00:14:50,729 --> 00:14:54,169
Feature, das ist nicht ein Seiteneffekt,
sondern das ist einer der Gründe, warum

215
00:14:54,169 --> 00:14:58,849
man das überhaupt hat. Nutzt das auch.
Das ist nicht mehr… es tut nicht mehr weh,

216
00:14:58,849 --> 00:15:02,210
wenn man was kaputtmacht im Build,
sondern dann kann ich zurückrollen. Nicht

217
00:15:02,210 --> 00:15:06,509
nur im Versionierungssystem, sondern ich
kann auch einfach komplett, einen neuen

218
00:15:06,509 --> 00:15:10,679
Build, fällt dann halt raus. Und am besten
macht man sowas über die Mittagspause, ja?

219
00:15:10,679 --> 00:15:14,860
Daher vorhin der Ratschlag, im Skript
Abhängigkeiten testen. Und nicht nach zwei

220
00:15:14,860 --> 00:15:18,990
Stunden den Build failen lassen.
Docker ist… und Container sind

221
00:15:18,990 --> 00:15:22,389
eigentlich eine gute Idee. Aber die
meisten Leute nehmen nur die Nachteile

222
00:15:22,389 --> 00:15:29,689
mit. Komponenten kann man agil updaten.
Das muss man auch tun. Also ist hier keine

223
00:15:29,689 --> 00:15:32,559
schwarze Magie, die ich hier erzähle. Aber
es ist erstaunlich, wie viele Leute das

224
00:15:32,559 --> 00:15:37,100
nicht machen. Und der mir als Security-Typ
natürlich am wichtigsten erscheinende

225
00:15:37,100 --> 00:15:41,399
Aspekt bei Containern ist, dass man damit
Komponenten im Gesamtsystem isolieren kann

226
00:15:41,399 --> 00:15:45,970
voneinander. Dass nicht ein Typ, der
diesen einen Prozess hackt, automatisch

227
00:15:45,970 --> 00:15:49,949
alle anderen im Zugriff hat. Sondern die
laufen halt in ihren eigenen Containern.

228
00:15:49,949 --> 00:15:53,350
Aber in der Praxis sieht man, dass dann
der Monster-Container gebaut wird mit den

229
00:15:53,350 --> 00:16:00,300
50 Komponenten drin. Das ist nicht gut.
Also nehmt alle Vorteile mit. Richtig gut

230
00:16:00,300 --> 00:16:04,799
ist das natürlich erst in Kombination, ja?
Der Git hat alle Versionen und dem Build-

231
00:16:04,799 --> 00:16:07,830
Server kann ich eine Version zurufen und
dann fällt ein Image raus ohne

232
00:16:07,830 --> 00:16:13,099
Abhängigkeiten. So, wenn ihr das nicht
habt, dann benutzt ihr das nicht richtig.

233
00:16:13,099 --> 00:16:18,709
Ganz einfach. Das nächste Problem ist: Der
Code funktioniert nicht. Das kennen

234
00:16:18,709 --> 00:16:22,360
wahrscheinlich auch alle, ist ein Problem.
Was machen wir jetzt? Und die Lösung ist:

235
00:16:22,360 --> 00:16:27,809
Unit-Tests! Und die Umsetzung ist häufig:
ich habe hier gerade einen Bug, den fixe

236
00:16:27,809 --> 00:16:32,559
ich mal, und den Check, ob der Bug weg
ist, den mache ich jetzt als Unit-Test. Ja

237
00:16:32,559 --> 00:16:35,919
und das ist nicht gut. Da kriegt man dann
so eine Coverage von 2,3 Prozent, wenn es

238
00:16:35,919 --> 00:16:40,730
hoch kommt. Und ich weiß nicht, ob ihr
alle das Video hier gesehen habt. Das war

239
00:16:40,730 --> 00:16:43,839
so ein Automat, der erkennen sollte, ob
eine Hand drunter gehalten wurde. Und der

240
00:16:43,839 --> 00:16:48,199
wurde halt von Weißen gemacht. Und die
haben halt nie eine andere Hautfarbe

241
00:16:48,199 --> 00:16:52,560
getestet. Und da kommt dann halt nix raus.
So, das ist ein typischer Fall von „Unit-

242
00:16:52,560 --> 00:16:59,439
Test-Abdeckung zu gering“. Ich glaube
auch, dass hier die Perspektive die

243
00:16:59,439 --> 00:17:02,709
falsche ist häufig. Die Leute glauben, sie
machen Unit-Tests, damit sie wissen, dass

244
00:17:02,709 --> 00:17:08,299
der Code jetzt okay ist. Nein! Unit-Tests
sind dafür da, dass sich was ändern kann

245
00:17:08,299 --> 00:17:12,690
und [man] sehen kann, ob es -noch- geht.
Damit ich keine Angst mehr haben muss,

246
00:17:12,690 --> 00:17:17,160
alten Code anzufassen. Das ist das, was
Unit-Tests euch abnehmen: die Angst, in

247
00:17:17,160 --> 00:17:21,830
altem Code was zu fixen. Weil ihr den
nicht komplett versteht oder so. Und

248
00:17:21,830 --> 00:17:26,979
je mehr Abdeckung ihr mit den Unit-Tests
habt, desto stärker ist diese Waffe.

249
00:17:26,979 --> 00:17:35,540
Nutzt das.
*Applaus*

250
00:17:35,540 --> 00:17:38,810
Ich muss hier ein bisschen durchgaloppieren,
weil ich zu viele Folien habe. Ich hoffe,

251
00:17:38,810 --> 00:17:42,249
das verzeiht ihr mir. So, das nächste
Problem sind, dass die Leute nur positive

252
00:17:42,249 --> 00:17:47,230
Tests haben. Die gucken: funktioniert das
hier? Und der Effekt ist normalerweise so gut

253
00:17:47,230 --> 00:17:51,229
wie keiner, denn die ganzen interessanten
Bugs sind in der Fehlerbehandlung, dafür

254
00:17:51,229 --> 00:17:55,980
braucht ihr auch Unit-Tests. Und zwar
müsst ihr eigentlich für alles, was

255
00:17:55,980 --> 00:18:00,640
fehlschlagen kann, einen Test haben, der
das fehlschlagen lässt. Und dann gucken,

256
00:18:00,640 --> 00:18:05,620
ob das immer noch funktioniert, wie es
soll. Das sind die Sachen, die am Ende

257
00:18:05,620 --> 00:18:09,930
über Bande woanders einen Fehler erzeugen,
ja? Irgendwie eine Memory Corruption in

258
00:18:09,930 --> 00:18:13,699
einem Fehlerfall, oder irgendwie „RAM wird
nicht freigegeben im Fehlerfall“. Und dann

259
00:18:13,699 --> 00:18:16,840
stellt sich raus: das kann man als
Angreifer triggern. Und dann habe ich einen

260
00:18:16,840 --> 00:18:21,320
Remote-Memory-Leak und der Prozess crasht.
Diese Art von Sachen sind völlig überflüssig

261
00:18:21,320 --> 00:18:26,539
und mit ordentlichen Unit-Tests abfangbar.
Also macht das. Unit-Tests sind aber kein

262
00:18:26,539 --> 00:18:29,389
Allheilmittel, den Eindruck möchte ich
nicht vermitteln. Selbst wenn ich 100%

263
00:18:29,389 --> 00:18:33,010
Unit-Test-Coverage habe, kann ich
immer noch einen Fall übersehen haben.

264
00:18:33,010 --> 00:18:36,691
Dennoch: das ist ein Ziel, was ihr haben
solltet. Es gibt Tools, um die Coverage zu

265
00:18:36,691 --> 00:18:42,840
prüfen. Nutzt diese Tools. Das ist
wichtig. So, der nächste Fall, jetzt habe

266
00:18:42,840 --> 00:18:45,800
ich Unit-Tests ausgerollt, ist: die
Entwickler haben Fälle vergessen zu

267
00:18:45,800 --> 00:18:51,370
testen, ja? Das kommt häufig vor.
Und da gibt es einen neuen Hype: Test-

268
00:18:51,370 --> 00:18:55,340
Driven-Development. Du schreibst erst die
Tests und dann den Code. Und da kann ich

269
00:18:55,340 --> 00:18:58,810
leider nichts zu sagen, weil ich das noch
nie in der Produktion gesehen habe.

270
00:18:58,810 --> 00:19:02,100
Ich kenne nur Leute…

271
00:19:02,100 --> 00:19:07,220
*Lachen und Applaus*

272
00:19:07,220 --> 00:19:10,710
Ich kenne nur Leute, die sich ganz sicher
sind, dass das total geil ist. Aber ich

273
00:19:10,710 --> 00:19:13,130
habe es noch nie… also wenn ihr da
irgendwie wisst, dann schreibt mir mal

274
00:19:13,130 --> 00:19:16,990
eine Mail, das würde mich echt
interessieren. Ja, das nächste Problem

275
00:19:16,990 --> 00:19:20,330
ist: wir haben hier Code, und der tut
irgendwas, aber wir haben keine Ahnung,

276
00:19:20,330 --> 00:19:24,380
wie das funktioniert. Und die Lösung ist
natürlich: Dokumentation! Ist auch eine

277
00:19:24,380 --> 00:19:28,120
gute Idee, das will ich keinem ausreden.
Aber es kommt häufig vor, Seal Team 6

278
00:19:28,120 --> 00:19:32,860
setzt ein Wiki auf, und da gibt es ganz
häufig so Effekte – da werde ich hier

279
00:19:32,860 --> 00:19:38,120
Congress-Teilnehmern nichts Neues erzählen
– das Zertifikat ist gerade abgelaufen

280
00:19:38,120 --> 00:19:41,770
oder das Wiki wirft Exceptions oder ist
nicht erreichbar oder so. Das ist ganz

281
00:19:41,770 --> 00:19:47,350
häufig. Und dann fallen so Sätze wie: „Ja,
das hatte ich, glaube ich, ins Wiki getan“.

282
00:19:47,350 --> 00:19:52,369
Und so: „Ja, das musst du halt bookmarken,
weil Navigation haben wir noch nicht“. Und

283
00:19:52,369 --> 00:19:58,739
ganz häufig gibt es auch: „Jaja, das
hier oben, das stimmt nicht mehr“.

284
00:19:58,739 --> 00:20:04,240
Also Wiki ist keine Lösung. Je kleiner man
die Schwelle setzt dafür, da was zu

285
00:20:04,240 --> 00:20:08,529
editieren, desto mehr fällt es unter den…
vom Tisch. Weil die Leute

286
00:20:08,529 --> 00:20:12,319
einfach das nicht als als wichtigen
Schritt sehen, sondern als so kleines

287
00:20:12,319 --> 00:20:18,409
Ding. Das muss ein richtiger Schritt im
System sein, im Produktivbetrieb, dass

288
00:20:18,409 --> 00:20:23,340
man sagt: „Jede Änderung wird dokumentiert,
Punkt.“ So, die nächste Idee, die man in

289
00:20:23,340 --> 00:20:26,520
großen Firmen häufig hört, dass man sagt:
„Wir müssen hier mehr Kommunikation haben,

290
00:20:26,520 --> 00:20:32,620
die Leute reden zu wenig miteinander“. Und
dann hat man so Großraumbüros.

291
00:20:32,620 --> 00:20:40,880
*Lachen und Applaus*

292
00:20:40,880 --> 00:20:43,670
Habe ich auch noch nie
funktionieren sehen.

293
00:20:43,670 --> 00:20:46,440
Das klappt nicht, ja? Menschen
müssen sich mal am Stück konzentrieren

294
00:20:46,440 --> 00:20:50,029
können. Und je mehr Unterbrechung man hat,
desto schlechter ist das. Und heute geht

295
00:20:50,029 --> 00:20:52,300
der Trend sogar dahin…

296
00:20:52,300 --> 00:20:57,810
*Applaus*

297
00:20:57,810 --> 00:21:00,879
Heute geht der Trend sogar dahin, dass die
Leute sich Slack installieren. Die

298
00:21:00,879 --> 00:21:05,070
plakatieren gerade in Berlin. Also, die
sich absichtlich gegenseitig unterbrechen.

299
00:21:05,070 --> 00:21:08,570
Ist mir völlig ein Rätsel, warum Leute
sowas tun würden. Denn nach jeder

300
00:21:08,570 --> 00:21:12,040
Unterbrechung braucht man so eine
Viertelstunde, bis man wieder drin ist.

301
00:21:12,040 --> 00:21:16,899
Und diese Chatsysteme und auch Mail-
Unterbrechungen sind darauf ausgelegt,

302
00:21:16,899 --> 00:21:22,130
dass man nie diese 15 Minuten schafft.
Ja, ich weiß, die Zeit ist knapp, ist gut!

303
00:21:22,130 --> 00:21:23,690
*lacht*
*Lachen*

304
00:21:23,690 --> 00:21:29,899
Meetings, ja. Meetings. Da muss ich,
glaube ich, nicht viel zu sagen.

305
00:21:29,899 --> 00:21:32,460
Aber der Effekt ist immer derselbe: ich
kann mich nicht konzentrieren. Und das

306
00:21:32,460 --> 00:21:35,920
ist ein ernstes Problem.
Da muss man aktiv gegenhalten,

307
00:21:35,920 --> 00:21:39,230
ja? Das ist nicht so einfach. Ich habe
jetzt überlegt: soll ich vorschlagen, die

308
00:21:39,230 --> 00:21:42,389
Meetings kurz zu machen? Aber das ist so,
habe ich auch nie funktionieren sehen, den

309
00:21:42,389 --> 00:21:46,779
Ratschlag. Alle Leute glauben immer, sie
machen ihre Meetings kurz. Funktioniert

310
00:21:46,779 --> 00:21:51,720
nicht. Daher sage ich: lieber selten und
One-on-One. Denn wenn man jetzt irgendein

311
00:21:51,720 --> 00:21:55,580
Problem klären will, und da sitzen alle
Leute aus dem Team, dann gibt es eine

312
00:21:55,580 --> 00:21:58,230
höhere Schwelle für den Einzelnen, zu
sagen: „Ja, da habe ich einen Fehler

313
00:21:58,230 --> 00:22:01,300
gemacht.“ Deswegen lieber einzeln.

314
00:22:01,300 --> 00:22:04,790
*Applaus*

315
00:22:04,790 --> 00:22:08,769
Niemand, niemand hat Bock darauf, sich vor
seinen Kollegen zu entblößen. Und das muss

316
00:22:08,769 --> 00:22:13,370
man also nicht künstlich herbeiführen. So,
jetzt kommen wir zur Security-Abteilung.

317
00:22:13,370 --> 00:22:16,230
Wir haben Code und er tut irgendwas, aber
wir trauen dem nicht. Was machen wir

318
00:22:16,230 --> 00:22:22,211
jetzt? Nächste Idee: naja okay, wir machen
erstmal die Compiler-Warnungen weg, ja?

319
00:22:22,211 --> 00:22:26,489
Gute Idee. Der Effekt ist – und ich war
schockiert, dass es da einen Begriff für

320
00:22:26,489 --> 00:22:31,290
gibt: Onion-Code. So, Onion-Code bedeutet,
dass ich so einen Chunk Legacy-Code habe,

321
00:22:31,290 --> 00:22:34,769
der total viele Warnungen drin hat, und
den seit fünf Jahren keiner mehr angefasst

322
00:22:34,769 --> 00:22:39,160
hat. Und da findet jetzt jemand einen Bug
drin. Und der würde den gerne fixen. Aber

323
00:22:39,160 --> 00:22:43,190
dann compilet der Rest immer noch mit den
ganzen Warnungen. Und die müsste ich dann

324
00:22:43,190 --> 00:22:47,220
fixen, damit ich den Fix einchecken kann
für den Bug. Und ich verstehe diesen Code

325
00:22:47,220 --> 00:22:50,669
aber nicht. Ich verstehe nur den kleinen
Teil, wo ich den Bug gefunden habe. Und

326
00:22:50,669 --> 00:22:55,750
dann mache ich einen Layer drum rum, und
der guckt diesen einen Fall, fängt ihn ab.

327
00:22:55,750 --> 00:22:59,060
Und wenn das mehrere Leute machen, hat man
so eine Zwiebel. Und deswegen heißt das

328
00:22:59,060 --> 00:23:03,749
Onion-Code. Das ist ganz furchtbar, ja?

329
00:23:03,749 --> 00:23:09,590
Wenn ihr das irgendwo seht,
dann ‚burn it with fire‘!

330
00:23:09,590 --> 00:23:12,819
So, nächster Vorschlag: wir haben nur noch
Releases ohne offene Bugs. Das klingt auch

331
00:23:12,819 --> 00:23:17,280
total super. Und ich war auch mal bei
einem Kunden, der das probiert hat,

332
00:23:17,280 --> 00:23:22,010
und da kam dann so eine Mail:
„Mach mal deine Bugs alle zu.“ Und

333
00:23:22,010 --> 00:23:24,620
dann meine ich so: „Ich bin aber hier,
um Bugs aufzumachen, nicht um sie

334
00:23:24,620 --> 00:23:28,349
zuzumachen.“ Und dann meinte er: „Ja,
die machen wir danach wieder auf, keine

335
00:23:28,349 --> 00:23:36,689
Sorge.“
*Lachen und Applaus*

336
00:23:36,689 --> 00:23:40,590
Muss ich, glaube ich, nicht erläutern, ob
die wieder aufgemacht wurden oder nicht.

337
00:23:40,590 --> 00:23:43,719
Ja, externer Audit, und das tut mir in der
Seele weh, denn das biete ich geschäftlich

338
00:23:43,719 --> 00:23:47,549
an, ja, das ist leider auch teilweise ein
Antipattern. Denn was hier passiert, ist,

339
00:23:47,549 --> 00:23:51,689
dass die Leute so einen Blackbox-Pentest
beauftragen. Und ein Blackbox-Pentest

340
00:23:51,689 --> 00:23:54,700
heißt, der Tester hat keinen vollen
Zugriff auf das System, der weiß nicht,

341
00:23:54,700 --> 00:23:57,799
wie das funktioniert, sondern soll das in
dem Test selber rausfinden. Und dann

342
00:23:57,799 --> 00:24:02,259
passiert sowas hier. Und was mich an der
Stelle am meisten beeindruckt hat, ist,

343
00:24:02,259 --> 00:24:07,480
dass es dieses Bild schon gab. Das habe
ich jetzt nicht gemacht. So, das ist

344
00:24:07,480 --> 00:24:12,089
leider üblich. Man testet nicht den Code,
sondern man testet den Pentester. Und ich

345
00:24:12,089 --> 00:24:15,349
als Pentester habe jetzt natürlich… könnte
jetzt sagen: „Ja, ist mir doch egal, wen

346
00:24:15,349 --> 00:24:19,579
die da testen, solange ich bezahlt werde.“
Aber ich habe da so einen Moralkodex. Ich

347
00:24:19,579 --> 00:24:23,072
hätte gern dem Kunden geholfen und nicht
nur das Geld genommen. Das ist für alle

348
00:24:23,072 --> 00:24:27,462
Seiten Scheiße. Macht das nicht. Ja,
Pentests. Ich sage, das ist ein

349
00:24:27,462 --> 00:24:31,719
Compliance-Problem, dass die Leute alle
aus Compliance-Gründen Pentests machen.

350
00:24:31,719 --> 00:24:35,300
Und das ist eigentlich an sich schon ein
furchtbares Zeichen, dass wir die Security

351
00:24:35,300 --> 00:24:38,930
nicht hinkriegen, sondern Compliance
brauchen, um uns dazu zu bringen, dass wir

352
00:24:38,930 --> 00:24:44,989
doch Security machen. Wir sollten uns alle
schämen! Fuzzing ist auch so ein Ding. Das

353
00:24:44,989 --> 00:24:49,500
wird gerne gemacht. Fuzzing heißt, dass
ich zufällige Eingaben generiere und gegen

354
00:24:49,500 --> 00:24:52,959
meinen Endpunkt werfe und gucke, ob der
platzt oder nicht. Und das ist

355
00:24:52,959 --> 00:24:56,929
erschütternd erfolgreich, ja? Das
funktioniert. Und ich habe mal erlebt,

356
00:24:56,929 --> 00:24:59,731
dass sie gesagt haben: „Nee, den Code
hier, den musst du nicht testen, den haben

357
00:24:59,731 --> 00:25:04,100
wir schon zu Tode gefuzzt. Seit Monaten
läuft unsere Fuzzing-Farm.“ Und da stellt

358
00:25:04,100 --> 00:25:06,999
sich dann heraus: die haben zwar
Milliarden von Test-Cases geprüft. Aber

359
00:25:06,999 --> 00:25:11,809
das war immer derselbe.
*Lachen*

360
00:25:11,809 --> 00:25:16,000
Total super. Und häufig ist Fuzzing so ein
Feigenblatt, womit dann andere Maßnahmen

361
00:25:16,000 --> 00:25:18,470
nicht gemacht werden, weil wir haben doch
schon gefuzzt, und das ist auch in

362
00:25:18,470 --> 00:25:21,989
Ordnung, ja? Also ich habe nichts gegen
Fuzzing an sich, denn es funktioniert

363
00:25:21,989 --> 00:25:31,610
leider. Aber es darf kein Hindernis dafür
sein, andere wichtige Maßnahmen zu machen.

364
00:25:31,610 --> 00:25:35,230
Das ist ein generelles Problem, was ich
häufiger sehe, dass, wenn das Management

365
00:25:35,230 --> 00:25:39,579
die Wahl hat zwischen einer Maßnahme, die
wahrscheinlich funktioniert, aber keine

366
00:25:39,579 --> 00:25:43,379
Metriken abwirft, und einer Maßnahme, die
wahrscheinlich nicht funktioniert, aber

367
00:25:43,379 --> 00:25:48,199
Metriken abwirft, dass immer die mit den
Metriken gemacht wird. Management liebt

368
00:25:48,199 --> 00:25:51,900
qualifizierbare Geschichten, wo irgend…
quantifizierbare Geschichten, wo

369
00:25:51,900 --> 00:25:56,279
irgendeine Zahl rausfällt. Und das geht
häufig nach hinten los, ja? Ich habe also

370
00:25:56,279 --> 00:26:01,630
mal so ein… das war ein wirklich
schockierendes Erlebnis für mich. Ich bin,

371
00:26:01,630 --> 00:26:05,820
ich sage mal preiswert, aber nicht billig,
ja, also meine Tagessätze. – Ich weiß, ich

372
00:26:05,820 --> 00:26:11,160
weiß! – So und dann gehe ich dahin, zu dem
Kunden, und der Kunde sagt: „Geh mal nach

373
00:26:11,160 --> 00:26:15,360
Hause.“ Also ich wurde trotzdem bezahlt,
ja? Haben gesagt: „Geh mal nach Hause.“

374
00:26:15,360 --> 00:26:19,730
Und ich so: „Wie jetzt?“ „Ja, ist warm
heute.“ Meinte ich so: „Was?“ „Ja die

375
00:26:19,730 --> 00:26:23,110
Klimaanlage reicht für das Fuzzing-Lab
oder die Consultants.“

376
00:26:23,110 --> 00:26:31,720
*Lachen und Applaus*
Ja. Gut. Das nächste Problem, das ist so

377
00:26:31,720 --> 00:26:35,580
ein bisschen schwierig. Aber es ist mir
sehr wichtig, weil das so gerade im Kommen

378
00:26:35,580 --> 00:26:40,650
ist. Die Coder sind überfordert. Und dann
sagt man: wir brauchen irgendeinen soliden

379
00:26:40,650 --> 00:26:43,820
Ansatz. Thread-Modeling! Das ist gerade
im Kommen. Und das ist eine gute

380
00:26:43,820 --> 00:26:47,520
Geschichte, aber es wird häufig
missverstanden. Thread-Modeling, der

381
00:26:47,520 --> 00:26:50,890
übliche Ansatz ist, dass man sagt: jedes
Team macht ein Thread-Model für den Code.

382
00:26:50,890 --> 00:26:56,419
Das ist gut. Ja? Aber häufig macht dann
der Feature-Owner oder Projektmanager

383
00:26:56,419 --> 00:27:00,350
mit dem Dokumentationsteam zusammen, füllt
irgendwelche Formulare aus, und die

384
00:27:00,350 --> 00:27:05,049
Developer sind überhaupt nicht betroffen.
Und das ist ein krasser Fehler. Denn beim

385
00:27:05,049 --> 00:27:09,079
Thread-Modeling geht es nicht um das
Papier am Ende. Das ist kein Zertifikat.

386
00:27:09,079 --> 00:27:13,549
Sondern es geht um den Weg zum Papier. Es
geht darum, dass die Entwickler mal aus

387
00:27:13,549 --> 00:27:17,229
der Sicht des Angreifers versuchen, auf
ihren Code zu gucken, dass sie verstehen,

388
00:27:17,229 --> 00:27:21,239
was da Angriffsoberfläche ist, dass sie
sehen, wo die Sachen sind, auf die man

389
00:27:21,239 --> 00:27:25,099
aufpassen muss, welche Angriffe denkbar
sind. Wenn jemand anderes das Thread-Model

390
00:27:25,099 --> 00:27:29,720
macht, das hätte man sich auch sparen
können, ja? Also: Thread-Model ist gut,

391
00:27:29,720 --> 00:27:34,230
aber das müssen die Entwickler machen. Wir
sind fast durch. Ich habe noch ein paar

392
00:27:34,230 --> 00:27:37,060
allgemeine Ratschläge, weil ich mir
dachte: ich kann euch hier nicht so

393
00:27:37,060 --> 00:27:41,819
deprimiert nach Hause gehen lassen. Aus
Sicht des Management ist aus meiner Seite

394
00:27:41,819 --> 00:27:44,800
ganz wichtig, dass man eine Fehlerkultur
etabliert. Das heißt: niemand wird

395
00:27:44,800 --> 00:27:48,389
bestraft für Bugs. Denn sonst verstecken
die Leute Bugs, und das ist noch

396
00:27:48,389 --> 00:27:51,610
schlechter, ja? Man muss Leute belohnen,
…

397
00:27:51,610 --> 00:27:58,231
*Applaus*
Man muss Leute belohnen, wenn sie

398
00:27:58,231 --> 00:28:02,239
einen Bug finden und fixen. Aber nicht
mit Geld belohnen, sondern mit Ruhm und

399
00:28:02,239 --> 00:28:06,860
Ehre. Ich schlage immer vor, einmal die
Woche, irgendwie Freitag ab 4 oder so,

400
00:28:06,860 --> 00:28:12,759
macht man so ein All-Hands-Meeting, wo –
wenn die Leute wirklich was Anderes

401
00:28:12,759 --> 00:28:17,069
vorhaben, müssen sie nicht hingehen, also
kein Zwang – aber wo dann die alten

402
00:28:17,069 --> 00:28:22,159
Hasen ihre schönsten Bugs erklären, ja?
Damit es als etwas Positives gesehen wird,

403
00:28:22,159 --> 00:28:25,830
einen Bug zu finden, und damit die Jungen
was dabei lernen. Das ist eine gute Sache,

404
00:28:25,830 --> 00:28:29,089
das kann ich empfehlen. Das funktioniert
auch gut, und das bringt auch das Team

405
00:28:29,089 --> 00:28:35,009
zusammen. Und es nimmt so diesen Rockstar-
Status weg, der auch nur schadet. So, die

406
00:28:35,009 --> 00:28:38,870
nächste Sache ist, dass man dafür sorgt,
dass der Bug auch von dem gefixed wird,

407
00:28:38,870 --> 00:28:42,650
der den Code geschrieben hat. Es gibt
große Firmen, die teilweise ein zweites

408
00:28:42,650 --> 00:28:46,729
Team dafür haben, Sicherheits-Bugs zu
fixen. Und dann kriegt der Typ, der das

409
00:28:46,729 --> 00:28:49,320
programmiert hat, überhaupt nicht mit,
dass er die ganze Zeit schlechten Code

410
00:28:49,320 --> 00:28:52,880
programmiert. Der zieht dann am besten
noch so von Team zu Team, hinterlässt

411
00:28:52,880 --> 00:28:57,409
überall so Tretminen. Das ist wichtig,
dass es Feedback gibt. Und zwar nicht als

412
00:28:57,409 --> 00:29:00,650
Strafe, sondern damit die Leute merken,
wenn sie Fehler machen, ja? Menschen

413
00:29:00,650 --> 00:29:04,010
lernen aus ihren Fehlern. Dafür muss man
verstehen, wenn man einen Fehler gemacht

414
00:29:04,010 --> 00:29:08,199
hat. Und das ist die, wo… komme ich
zurück zu dieser Meeting-Kultur. Wenn man

415
00:29:08,199 --> 00:29:11,680
ein Meeting hat und sagt: „Du hast hier
aber Scheiße gemacht“, dann macht man den

416
00:29:11,680 --> 00:29:15,640
vor dem ganzen Team nackig. Das hilft
überhaupt nicht, ja? Man… es ist auch

417
00:29:15,640 --> 00:29:19,369
eine Kulturkreis-Frage. Manche
Kulturkreise können damit besser umgehen

418
00:29:19,369 --> 00:29:24,980
als andere. Aber es gibt eben viele Leute,
die haben ein starkes Problem damit, dass

419
00:29:24,980 --> 00:29:28,160
ihnen gesagt wird: „Du hast einen Fehler
gemacht“, ja? Weil das, in Japan zum

420
00:29:28,160 --> 00:29:32,190
Beispiel ist es sehr wichtig, dass man der
Firma hilft und nicht gesehen wird, wie

421
00:29:32,190 --> 00:29:36,281
man irgendwie an irgendwas schuld ist.
Also das ist schwierig, so etwas

422
00:29:36,281 --> 00:29:40,209
aufzubauen. Aber das ist sehr wichtig.
Fehler sind nicht schlecht, sondern aus

423
00:29:40,209 --> 00:29:46,040
den Fehlern kann man lernen, ja? Fehler
sind gut. Dann finde ich, dass die Firma

424
00:29:46,040 --> 00:29:50,520
Werte kommunizieren sollte. Werte wie:
uns ist der Code wichtiger, die Güte des

425
00:29:50,520 --> 00:29:54,789
Codes ist wichtiger als die Quantität, ja?
Es kommt nicht darauf an, hier mehr Kram

426
00:29:54,789 --> 00:29:59,619
dran zu tun, sondern es kommt darauf an,
dass wir, wenn wir was geschrieben haben,

427
00:29:59,619 --> 00:30:02,820
da auch noch einmal darauf zurückkommen
später, ja? Wenn wir was dazugelernt

428
00:30:02,820 --> 00:30:07,929
haben, dass wir das auf den alten Code
anwenden. Und damit das stressfrei machbar

429
00:30:07,929 --> 00:30:12,600
ist, braucht man ordentliche Unit-Tests.
So haben wir dann so einen Kreisschluss.

430
00:30:12,600 --> 00:30:15,910
Die Anekdote, die ich hier erzählen
wollte, war, dass ich mit einem Freund

431
00:30:15,910 --> 00:30:20,690
einen Job hatte. Und da war… Teil von dem
Problem war ein User-Interface. Und da

432
00:30:20,690 --> 00:30:24,110
hatten wir beide überhaupt keine Ahnung
von. Und der Freund meinte dann ganz

433
00:30:24,110 --> 00:30:27,980
locker: „Ja lass uns das in Qt machen.“
Und ich meinte so: „Wir haben beide keine

434
00:30:27,980 --> 00:30:30,990
Ahnung von Qt. Was machst du hier?“ Und
da meint er: „Ja, das hätte ich gerne im

435
00:30:30,990 --> 00:30:34,319
Resümee stehen, ja? Das muss… in meinem
Lebenslauf sieht das gut aus.“ Das ist

436
00:30:34,319 --> 00:30:37,349
schon ein paar Jahre her. Aber was ich
sagen will: wenn die Firma den Leuten

437
00:30:37,349 --> 00:30:41,210
nicht die Zeit gibt, Sachen zu lernen,
dann lernen sie das in Projekten der

438
00:30:41,210 --> 00:30:45,390
Firma, und die werden dann Scheiße.

439
00:30:45,390 --> 00:30:55,130
*Applaus*

440
00:30:55,130 --> 00:30:58,450
Was man auch häufiger sieht, ist, dass das
Management glaubt, sie müsste die

441
00:30:58,450 --> 00:31:02,600
Architektur der Software vorgeben, oder
welche Datenbank verwendet wird oder so.

442
00:31:02,600 --> 00:31:05,480
Und das ist eigentlich auch immer eine
schlechte Idee. Denn entweder die

443
00:31:05,480 --> 00:31:08,659
Architektur ist offensichtlich, dann hilft
es nichts. Oder sie ist nicht

444
00:31:08,659 --> 00:31:11,060
offensichtlich, dann sind die Ratschläge
wahrscheinlich falsch, weil wir das

445
00:31:11,060 --> 00:31:14,730
Problem noch nicht wirklich verstanden
haben. Also das ist auch eine Sache, da

446
00:31:14,730 --> 00:31:18,490
sollte sich das Management
zurücknehmen an der Stelle.

447
00:31:18,490 --> 00:31:23,550
*Applaus*
Und hier noch so ein bisschen Selbsthilfe

448
00:31:23,550 --> 00:31:28,409
für Entwickler. Ist die letzte Folie, ganz
entspannt bleiben. Der Druck kommt immer

449
00:31:28,409 --> 00:31:32,690
von euch selbst. Das Management kann viel
erzählen, ja? Deadline hier, Deadline da.

450
00:31:32,690 --> 00:31:37,330
Lasst euch da nicht dazu bringen,
Überstunden zu fahren. Immer schön um 9

451
00:31:37,330 --> 00:31:44,280
kommen, um 5 nach Hause gehen. Also…
*Applaus*

452
00:31:44,280 --> 00:31:49,800
Wenn unrealistische Anforderungen
reinkommen, dann müsst ihr da ganz ehrlich

453
00:31:49,800 --> 00:31:52,910
sein und sagen: „Das wird wahrscheinlich
nicht klappen. Ich nehme jetzt euer Geld

454
00:31:52,910 --> 00:31:56,729
und arbeite daran. Aber ich sage euch
jetzt: das wird nix, ja?“ Immer schön

455
00:31:56,729 --> 00:32:00,460
Paper-Trail hinterlassen, dass das nichts
wird und man es rechtzeitig gesagt hat.

456
00:32:00,460 --> 00:32:03,230
Man kann dann dran arbeiten, weil viele
von euch werden wahrscheinlich die Kohle

457
00:32:03,230 --> 00:32:07,110
brauchen, aber ehrlich sein, nicht so tun,
als wenn wir das mit ein paar irgendwie

458
00:32:07,110 --> 00:32:10,920
die-Nacht-durchgemacht am Ende noch
reißen können. Das ist besonders in der

459
00:32:10,920 --> 00:32:15,600
Spielebranche ein riesiges Problem, dass
die Leute total Burnout kriegen. Man muss

460
00:32:15,600 --> 00:32:19,460
das verstehen mit dem Management wie ein
gegenseitiges Training, ja? Wenn ich dem

461
00:32:19,460 --> 00:32:22,969
Management so etwas durchgehen lasse,
dann zeige ich ihnen: das ist die neue

462
00:32:22,969 --> 00:32:25,609
Baseline, ja? Das erwarten die ab dann.

463
00:32:25,609 --> 00:32:27,570
Herald: Soll ich mir einen Stuhl holen,
damit ich mich daneben setze?

464
00:32:27,570 --> 00:32:28,939
Fefe: Kannst du machen,
das ist die letzte Folie.

465
00:32:28,939 --> 00:32:31,219
Herald: Okay.
Fefe: Ganz ruhig!

466
00:32:31,219 --> 00:32:33,769
So, und der letzte Satz,
den ich habe: Zeit ist… muss man sich

467
00:32:33,769 --> 00:32:36,240
selber nehmen, ja?
Ich habe zwar gerade gesagt…

468
00:32:36,240 --> 00:32:42,059
*Lachen und Applaus*

469
00:32:42,059 --> 00:32:50,299
Herald: Raus mit dir!
*weiter Applaus*

470
00:32:50,299 --> 00:32:52,910
Ich habe zwar gerade dem Management
empfohlen, euch Zeit zu geben,

471
00:32:52,910 --> 00:32:56,020
aber wenn ihr darauf wartet,
das wird nichts.

472
00:32:56,020 --> 00:32:59,540
*Lachen*
So, ich fürchte, die Fragezeit ist schon

473
00:32:59,540 --> 00:33:02,830
vorbei, oder?
Herald: Jo.

474
00:33:02,830 --> 00:33:13,519
*Lachen und Applaus*

475
00:33:13,519 --> 00:33:17,269
Das Beeindruckende ist ja wirklich:
die sind alle da geblieben, und da ist

476
00:33:17,269 --> 00:33:22,380
nicht einer vom Stuhl gefallen.
Fefe: Ja! *lacht*

477
00:33:22,380 --> 00:33:27,749
Herald: Vielen, vielen Dank! Ausgänge
sind beide offen. Das war’s von Fefe.

478
00:33:27,749 --> 00:33:30,339
Hier noch mal ein Applaus für ihn bitte!

479
00:33:30,339 --> 00:33:38,093
*Applaus*

480
00:33:38,093 --> 00:33:54,417
*Abspannmusik*

481
00:33:54,417 --> 00:33:59,301
*Untertitel erstellt von c3subtitles.de
im Jahr 2018*