WEBVTT
00:00:00.000 --> 00:00:15.720
34c3 preroll music
00:00:15.720 --> 00:00:20.940
Herald: Der Fefe hatte mich gebeten,
mich kurz zu halten, weil, er hat Angst,
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
00:00:26.740 --> 00:00:29.909
sage: „Antipatterns und Missverständnisse
in der Software-Entwicklung“!
00:00:29.909 --> 00:00:34.049
Und wie sagte jemand gestern?
„Ach Fefe! Das ist doch der mit der Kolumne
00:00:34.049 --> 00:00:37.870
beim ehemaligen Nachrichtenmagazin!“
Here we go!
00:00:37.870 --> 00:00:47.040
Applaus
00:00:47.040 --> 00:00:50.691
Fefe: Hallo hallo. Hallo hallo. Ja, ja
vielen Dank, dass ihr so zahlreich
00:00:50.691 --> 00:00:53.350
erschienen seid. Ein bisschen zahlreicher,
als ich gedacht habe. Nächstes Mal mache
00:00:53.350 --> 00:00:59.260
ich doch lieber parallel zu Minkorrekt
wieder. Es geht um Antipatterns.
00:00:59.260 --> 00:01:04.170
Antipatterns sind Sachen, die man macht,
die man häufig macht, die populäre
00:01:04.170 --> 00:01:07.820
Maßnahmen sind, um ein Problem zu lösen,
die dann aber entweder gar nicht
00:01:07.820 --> 00:01:13.680
funktionieren oder nach hinten losgehen.
Und ich habe mir gedacht, beim Congress
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.
00:01:17.840 --> 00:01:20.350
Und das hier ist so ein Motto, was
ich sehr profunde finde, und wo ihr
00:01:20.350 --> 00:01:25.850
hoffentlich im Laufe des Vortrags sehen
werdet, warum das das Motto ist. Ja, „wer
00:01:25.850 --> 00:01:31.530
lesen kann, aber es nicht tut, hat keinen
Vorteil dem gegenüber, der das nicht kann“.
00:01:31.530 --> 00:01:36.330
Die Struktur des Vortrags…
Applaus
00:01:36.330 --> 00:01:41.720
Die Struktur des Vortrags will ich an
einem Beispiel kurz umreißen.
00:01:41.720 --> 00:01:45.640
Es geht immer damit los,
dass wir ein Problem haben.
00:01:45.640 --> 00:01:50.380
Dann geht immer Seal Team 6
los und hackt irgendwas.
00:01:50.380 --> 00:01:53.280
Also denkt euch hier ein Team von
Spezialexperten. Ja ich will jetzt nicht
00:01:53.280 --> 00:01:58.190
die Seals beleidigen, bestimmt auch alles
nette Leute. Und dann kommt eine Umsetzung,
00:01:58.190 --> 00:02:02.780
da geht es meistens in die Hose.
Und dann haben wir einen Effekt, und
00:02:02.780 --> 00:02:08.390
hoffentlich, hoffentlich eine Erkenntnis
gewonnen. Ich habe mir gedacht, wir
00:02:08.390 --> 00:02:11.840
versuchen mal so eine interaktive
Komponente. Und zwar wenn man sich so
00:02:11.840 --> 00:02:15.920
Übertragungen aus dem britischen Parlament
ansieht, dann gibt es immer so ein
00:02:15.920 --> 00:02:19.372
Gemurmel, wenn die Leute zustimmen. Und
ich dachte mir, wenn ich sage, „Hebt mal
00:02:19.372 --> 00:02:23.190
den Arm, wenn euch das mal passiert ist“,
dann haben die Leute vielleicht Angst, auf
00:02:23.190 --> 00:02:26.690
dem Stream zu landen und sich zu outen.
Deswegen dachte ich, wir murmeln mal. Also
00:02:26.690 --> 00:02:30.020
wenn einer von euch sich bei einem Muster
wiedererkennt, könnt ihr mal versuchen.
00:02:30.020 --> 00:02:34.210
Wir gucken mal, ob das klappt. Ja,
vielleicht hört man das dann. Okay.
00:02:34.210 --> 00:02:38.690
Also, erstes Problem. Dieses Bild, ich
möchte das gleich dazusagen,
00:02:38.690 --> 00:02:44.680
Lachen
ist mir gespendet worden.
00:02:44.680 --> 00:02:48.339
Ich liefere hier keine Kunden ans Messer,
und es geht nur um Anekdoten.
00:02:48.339 --> 00:02:52.599
Also wer sich glaubt, wiederzuerkennen,
liegt wahrscheinlich falsch.
00:02:52.599 --> 00:02:56.040
So, das ist ein typisches Problem
in der Software-Entwicklung:
00:02:56.040 --> 00:03:00.010
die Versionierung von und die Backups
von alten Versionen aufzuheben.
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.
00:03:05.220 --> 00:03:07.950
Und die typische Idee ist: Wir machen
jetzt mal ein Versionierungssystem!
00:03:07.950 --> 00:03:11.800
Und das ist eine gute Idee. Die
Umsetzung ist dann gewöhnlich:
00:03:11.800 --> 00:03:14.820
der, der gerade ein akutes
Problem hat, bastelt schnell was,
00:03:14.820 --> 00:03:18.550
und dann kriegt man so ein Git. Und Git
ist eigentlich gut, aber man hat halt
00:03:18.550 --> 00:03:22.960
nicht nur Git, sondern man hat dann noch
so ein paar andere Versionierungssysteme,
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
00:03:27.129 --> 00:03:30.070
einen Kunden gehabt, die meinten: „Ist im
Git“, und dann meinte der Typ daneben:
00:03:30.070 --> 00:03:33.009
„Ja, musst noch sagen, in welchem“.
Also das kommt vor.
00:03:33.009 --> 00:03:36.379
Lachen
Ein anderer Effekt, den man häufig
00:03:36.379 --> 00:03:40.770
sieht, ist, dass jeder überall einchecken
darf. Und das führt dann zu so Sachen wie:
00:03:40.770 --> 00:03:45.540
man meldet als Bug so was wie: „In dem
Image sind aber noch set-UID-Binaries“
00:03:45.540 --> 00:03:48.540
oder sowas. Und dann machen die die alle
weg, und dann installiert man die nächste
00:03:48.540 --> 00:03:52.040
Version, und dann sind wieder welche, und
dann sagt der Typ: „Ja, ich habe die zwar
00:03:52.040 --> 00:03:55.850
alle weg gemacht, aber hat halt ein
Developer wieder rein gemacht“.
00:03:55.850 --> 00:04:00.270
Also Versionierung reicht noch nicht.
Da muss man noch mehr machen.
00:04:00.270 --> 00:04:04.470
Überhaupt die Idee, dass Leute Binaries
einchecken, ist eine ganz schlechte.
00:04:04.470 --> 00:04:07.010
Das findet man immer wieder.
Ich rede jetzt hier nicht von png
00:04:07.010 --> 00:04:11.140
oder irgendwie ein mpeg von einer Webseite
oder sowas, sondern so eine Library oder
00:04:11.140 --> 00:04:14.750
ein Executable. Das sollte man
eigentlich nicht tun.
00:04:14.750 --> 00:04:17.790
Es gibt ganz wenige Ausnahmen.
Wenn ihr eine von den Ausnahmen habt,
00:04:17.790 --> 00:04:21.400
wisst ihr es, und ansonsten
macht es nicht!
00:04:21.400 --> 00:04:23.790
Das hier ist jetzt natürlich überspitzt,
aber so ähnlich habe ich das schon
00:04:23.790 --> 00:04:27.410
mal gesehen, dass Leute verschiedene
Versionen einchecken, aber nicht
00:04:27.410 --> 00:04:31.210
verstanden haben, was eigentlich die Aufgabe
von so einem Versionierungssystem ist.
00:04:31.210 --> 00:04:36.910
Das ist auch nicht gut, macht das nicht!
00:04:36.910 --> 00:04:41.330
Ich habe dann immer so einen Ratschlag
am Ende von den jeweiligen Antipatterns.
00:04:41.330 --> 00:04:44.710
Und mein Ratschlag für Versionierungssysteme
ist: Git ist schon in Ordnung.
00:04:44.710 --> 00:04:48.240
Ich bin mir der Ironie bewusst, dass meine
eigene Software im Moment als CVS
00:04:48.240 --> 00:04:51.490
im Internet ist. Das hat historische Gründe!
00:04:51.490 --> 00:04:57.852
Lachen und Applaus
00:04:57.852 --> 00:05:02.562
Patches hält man am besten klein, damit
man sie einzeln anfassen kann,
00:05:02.562 --> 00:05:05.080
wenn sie nicht sauber applyen.
Das ist ein Riesenproblem, wenn jemand
00:05:05.080 --> 00:05:07.710
so einen Megabyte-Patch abliefert.
Deswegen macht das nicht.
00:05:07.710 --> 00:05:12.170
Wenn ihr größere Sachen vorbereiten müsst,
dann macht das nicht als einen großen
00:05:12.170 --> 00:05:15.790
Patch, sondern nehmt einen eigenen Branch
dafür. So ein Versionierungssystem will
00:05:15.790 --> 00:05:20.960
euch helfen. Also beschäftigt euch mit den
Features, die sie euch bieten.
00:05:20.960 --> 00:05:24.660
Wenn man Annahmen hat, über, welche APIs
verfügbar sind, oder welche Versionen von
00:05:24.660 --> 00:05:29.190
Komponenten drin sein sollen, sollte man
das im Build in einem Skript checken.
00:05:29.190 --> 00:05:32.709
Und nicht erst anfangen zu bauen, und nach
zwei Stunden abbrechen, weil irgendwas
00:05:32.709 --> 00:05:36.210
nicht geklappt hat. Sowas möglichst
vorher testen, damit es schnell failt,
00:05:36.210 --> 00:05:39.280
damit man schnell reagieren kann.
00:05:39.280 --> 00:05:42.660
Es gibt häufig so die Idee in Firmen, dass
man verschiedene Abteilungen hat und jede
00:05:42.660 --> 00:05:47.470
hat ihr eigenes Versionierungssystem oder
ihr eigenes Repository. Und das kann
00:05:47.470 --> 00:05:52.159
funktionieren, aber es ist sehr selten, ja?
Häufig, der… der…
00:05:52.159 --> 00:05:55.980
die Sache, die stimmen muss, damit es
klappt, ist, dass die APIs stabil sind.
00:05:55.980 --> 00:05:59.200
Und erfahrungsgemäß glauben alle, dass
ihre APIs stabil bleiben werden, und
00:05:59.200 --> 00:06:04.820
sie sind es dann aber nie. Also wenn ihr
das vermeiden könnt, macht das nicht.
00:06:04.820 --> 00:06:07.820
So, das nächste Problem ist: die Bugs
fallen immer unter den Tisch, werden
00:06:07.820 --> 00:06:11.450
vergessen, gefixt zu werden. Und die
offensichtliche Lösung ist:
00:06:11.450 --> 00:06:15.910
wir machen so einen Bugtracker.
Umsetzung ist natürlich wie immer Seal
00:06:15.910 --> 00:06:20.840
Team 6. Und der Effekt, der sich ganz
schnell einstellt, ist, dass man merkt,
00:06:20.840 --> 00:06:25.660
man hat ganz viele Bugs. Und das
ist dann gleich das nächste Problem:
00:06:25.660 --> 00:06:29.470
wir haben so viele Bugs,
was machen wir jetzt?
00:06:29.470 --> 00:06:32.609
Eine Sache, die ich inzwischen als
Antipattern sehe, ist: Priorisieren von
00:06:32.609 --> 00:06:37.510
Bugs. Ja, so eine übliche Umsetzung ist:
man hat sowas wie „Severity: Blocker“
00:06:37.510 --> 00:06:41.760
oder das ist ein Security-Bug – das soll
hier eine Checkbox sein. Und der Effekt
00:06:41.760 --> 00:06:45.670
davon ist, dass alle anderen Bugs liegen
bleiben. Das kann man immer und immer
00:06:45.670 --> 00:06:49.830
wieder beobachten. Also die… der
eigentliche… was ich so beobachte, der,
00:06:49.830 --> 00:06:52.759
der Effekt, der die meisten Bugs tötet,
ist, wenn eine Komponente einfach
00:06:52.759 --> 00:06:55.930
abgeschafft wird. Und dann kann man
alles schließen in der Komponente.
00:06:55.930 --> 00:06:59.550
Dass tatsächlich mal sowas
weggeht, gibt es nicht.
00:06:59.550 --> 00:07:04.240
Applaus
Es gibt ein schönes Wort dafür, wo mir
00:07:04.240 --> 00:07:09.419
jetzt die Übersetzungsteams bisschen leid
tun, nämlich Bug-Welle, im Sinne von einer
00:07:09.419 --> 00:07:14.040
Bugwelle vor so einem Tanker. Ich versuche
das gerade mal zu etablieren, als Begriff.
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,
00:07:18.080 --> 00:07:22.300
was machen wir denn jetzt? Nächstes
Problem. Und eine Idee, die häufig kommt,
00:07:22.300 --> 00:07:27.320
und die auch erstmal total super klingt,
ist, dass man bug-freien Code belohnt.
00:07:27.320 --> 00:07:31.389
Und zwar am besten mit so einem Bonus, am
besten in Geld. Wenn euer Team keine
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
00:07:36.780 --> 00:07:40.849
passiert, dass ich so eine Mail gekriegt
habe von einem Typ, wo ich ein paar Bugs
00:07:40.849 --> 00:07:45.290
gefilet habe, und der kommt und meint: „Du
Arschloch, jetzt ist mein Bonus weg. Ich
00:07:45.290 --> 00:07:50.560
kann meine Hypothek nicht abzahlen!“
Und da wusste ich dann auch erstmal nicht
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
00:07:55.319 --> 00:07:59.920
zugemacht hat und zwar mit NOTABUG.
Lachen
00:07:59.920 --> 00:08:02.610
Hat mir natürlich versprochen, dass die
trotzdem alle gefixt werden. Aber das
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
00:08:07.030 --> 00:08:11.539
Vorsicht zu genießen. Reward- und
Incentives-Sachen am besten nicht mit
00:08:11.539 --> 00:08:16.809
Geld. Es gibt auch ein Anti-Antipattern
dazu. Nämlich habe ich mal erlebt, dass
00:08:16.809 --> 00:08:20.990
jemand alle Bugs im Code gefixed hat, aber
im Bugtracker waren die noch offen. Und
00:08:20.990 --> 00:08:23.920
dann habe ich nicht verstanden, bin
hingegangen, und dann hat er mir erklärt:
00:08:23.920 --> 00:08:26.330
„Ja, die brauchen mich ja nicht mehr,
wenn die Bugs zu sind.“
00:08:26.330 --> 00:08:29.090
Lachen und Applaus
Der hat halt gesehen, hat halt gesehen, um
00:08:29.090 --> 00:08:34.629
ihn rum die Kollegen sind alle nach Indien
abgeschoben worden, die Projekte, und
00:08:34.629 --> 00:08:37.779
hat sich gedacht: „Na, die lass ich lieber
offen, die Bugs, dann werde ich hier noch
00:08:37.779 --> 00:08:41.639
ein paar Monate bezahlt.“ Das hat mir
echt, das fand ich echt atemberaubend.
00:08:41.639 --> 00:08:45.369
Da habe ich so ein paar Tage schlecht
geschlafen. Weil das ist ja schon… was
00:08:45.369 --> 00:08:49.040
für ein Selbstbild hat der denn, wenn er
glaubt, irgendwie diese, diese Einträge im
00:08:49.040 --> 00:08:53.630
Bugtracker halten ihn da am Leben? Ganz
furchtbar. Aber das gibt es in kleineren
00:08:53.630 --> 00:09:00.040
Ausmaßen häufiger, dass Leute Bugs offen
lassen, weil sie wissen: wenn die Bugs weg
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
00:09:05.050 --> 00:09:08.830
Woche Luft zu haben, ist einfach, die Bugs
nicht zu fixen. Das gibt es häufiger,
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
00:09:12.429 --> 00:09:18.599
wetten: ja. Das ist ein häufiges Pattern.
Das ist auch ein Klassiker hier. Man hat
00:09:18.599 --> 00:09:22.470
ein tolles Projekt, und das ist wunderbar,
aber es funktioniert nur auf dem Rechner
00:09:22.470 --> 00:09:26.889
vom Entwickler. Und die Idee ist: man hat
jetzt einen Build-Server, ja? Wir haben
00:09:26.889 --> 00:09:29.779
jetzt einen Build-Server, da wird
gebaut, das ist eine neutrale Umgebung,
00:09:29.779 --> 00:09:33.709
alles super. Seal Team 6 bastelt kurz
was, und das sieht auch echt geil aus, ja?
00:09:33.709 --> 00:09:38.269
Hier, so Drohnen-assistierte
Baugeschichten. Aber übliche Sachen, die
00:09:38.269 --> 00:09:42.540
halt fehlschlagen, ist, dass dieser Build-
Server von dem Team ist, und baut halt den
00:09:42.540 --> 00:09:47.160
Code von dem Team. Und die anderen Sachen
werden aus irgendwelchen antiken Snapshots
00:09:47.160 --> 00:09:50.939
von anderen Leuten reingezogen. Oder was
ich auch mal gesehen habe: dass Libraries
00:09:50.939 --> 00:09:56.019
dann so per SMB da reingelinkt werden.
Und das ist natürlich totale Scheiße, ja?
00:09:56.019 --> 00:10:01.719
Aber das passiert, so was passiert. Eine
häufige Sache, die man auch sieht, ist,
00:10:01.719 --> 00:10:04.760
dass man so einen Build-Server hat, aber
da muss dann jemand hinlaufen und so
00:10:04.760 --> 00:10:09.339
„Build“ klicken. Und das ist auch nicht
schlau. Ich habe hier mal versucht, ein
00:10:09.339 --> 00:10:16.129
Bild herauszusuchen. Die Idee beim
Build-Server ist es, dass der am besten
00:10:16.129 --> 00:10:20.669
automatisiert baut, und zwar mindestens
einmal täglich. So, das habe ich auch
00:10:20.669 --> 00:10:22.879
schon erlebt: der Build ist
fehlgeschlagen, und dann hat der
00:10:22.879 --> 00:10:25.749
Entwickler eben auf dem Build-Server
angefangen, irgendwelche Dateien zu
00:10:25.749 --> 00:10:31.470
editieren. Das ist jetzt gerade im
Wachstum von Devops ein Problem, was wir
00:10:31.470 --> 00:10:35.249
häufiger sehen werden, glaube ich. Das
macht natürlich den Vorteil vom Build-
00:10:35.249 --> 00:10:39.109
Server komplett kaputt, ja? Weil, dann habe
ich wieder den Effekt, das ist ja der
00:10:39.109 --> 00:10:42.639
Rechner vom Developer, aber es ist halt nicht
mehr der unter seinem Tisch, sondern in
00:10:42.639 --> 00:10:47.289
dem Rack da hinten, wo „Build-Server“
dransteht. So, ich hoffe, dass wir demnächst
00:10:47.289 --> 00:10:50.239
ein Debian haben werden, was diese
Namenskonvention übernimmt.
00:10:50.239 --> 00:10:53.750
Gelächter
Das sieht man auch häufig, ja, nicht nur
00:10:53.750 --> 00:10:56.529
auf Build-Servern, sondern das wird halt
irgendwann aufgesetzt und danach bleibt
00:10:56.529 --> 00:11:00.170
das halt so. Und das hält das ganze
Projekt zurück, weil dann irgendwelche
00:11:00.170 --> 00:11:04.259
Software-Versionen da drauf sind. So übliche
Sachen sind irgendwie eine SSL-Library,
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,
00:11:09.040 --> 00:11:12.919
das Problem. Oder irgendwie ein uraltes
C++, und dann können die Leute die neuen
00:11:12.919 --> 00:11:16.479
Features nicht benutzen. Also das ist
alles ganz furchtbar. Will das mal hier
00:11:16.479 --> 00:11:20.639
mit so einem schönen Müllhaufen
illustrieren. Der Grund, warum man einen
00:11:20.639 --> 00:11:25.190
Build-Server hat, ist, dass man täglich
bauen kann, automatisiert, ohne dass da
00:11:25.190 --> 00:11:29.879
jemand hingehen muss, und ohne dass jemand
hingehen kann, um irgendwas zu fixen. Da
00:11:29.879 --> 00:11:33.979
gibt es keine Interaktion außer: „Bau mal
diese Version“, ja? Der Build soll
00:11:33.979 --> 00:11:37.599
deterministisch sein. Das ist leider
unabhängig vom Build-Server, muss ich euch
00:11:37.599 --> 00:11:41.109
erzählen. Es gibt tatsächlich Build-
Prozesse, da fällt jedesmal ein anderes
00:11:41.109 --> 00:11:44.600
Binary raus, auch wenn man keine neue
Version ausgecheckt hat, weil irgendwie
00:11:44.600 --> 00:11:48.569
parallel gebaut wird und irgendwelche
Dateien, die gebraucht werden, werden
00:11:48.569 --> 00:11:52.209
asynchron von anderen Teilen aus dem
Parallel-Build erzeugt. Und wenn man Glück
00:11:52.209 --> 00:11:56.299
hat, kommt die richtige an. Und wenn man
Pech hat, halt nicht. Also das muss man
00:11:56.299 --> 00:12:00.959
fixen. Das ist Arbeit. Und es wäre mir
sehr lieb, dass so Open-Source-Entwickler
00:12:00.959 --> 00:12:06.719
auch alle dafür sorgen, dass ihre Projekte
mit beliebiger Parallelität baubar sind.
00:12:06.719 --> 00:12:09.819
Der nächste Grund für Build-Server
ist Agilität.
00:12:09.819 --> 00:12:12.179
Applaus
Ja? Wenn ich irgendwas kaputtgemacht habe,
00:12:12.179 --> 00:12:15.579
dann soll keine Panik ausbrechen, sondern
dann sage ich „Rollback“ und bau halt die
00:12:15.579 --> 00:12:19.349
Version von vorhin nochmal, die
funktioniert hat. Wenn das nicht ein
00:12:19.349 --> 00:12:23.690
Knopfdruck ist, dann könnt ihr den Build-
Server auch wegschmeißen. Und natürlich
00:12:23.690 --> 00:12:27.960
möchte man möglichst schnell mitkriegen,
wenn jemand was eingecheckt hat, was den
00:12:27.960 --> 00:12:32.419
Build bricht. Aber nicht sanktionieren!
Ich habe mal so eine Firma erlebt, die hat
00:12:32.419 --> 00:12:35.849
dann so ein Britney-Spears-T-Shirt gehabt,
und das musste der Typ tragen, der den
00:12:35.849 --> 00:12:38.489
letzten, zum letzten Mal den Build
gebrochen hat.
00:12:38.489 --> 00:12:43.720
Lachen und Applaus
Macht das nicht. Das hat gut funktioniert,
00:12:43.720 --> 00:12:46.410
bis sie so einen Britney-Spears-Fan als
Angestellten hatten.
00:12:46.410 --> 00:12:52.160
Lachen
Ja. So, also das nächste Problem: ich habe
00:12:52.160 --> 00:12:55.079
jetzt zwar einen Build-Server, und der
baut das zwar unabhängig vom
00:12:55.079 --> 00:12:58.460
Entwicklerrechner, aber das Binary
funktioniert nur auf dem Rechner vom
00:12:58.460 --> 00:13:03.859
Entwickler. Ist ein subtil anderes
Problem, aber verwandt. Und das löst man
00:13:03.859 --> 00:13:07.030
heute mit Docker, ist ja klar!
Applaus
00:13:07.030 --> 00:13:10.809
Und Docker ist im Prinzip keine schlechte
Idee. Man darf halt nicht Seal Team 6
00:13:10.809 --> 00:13:14.609
basteln lassen. Denn da kommen
dann so Effekte wie: ich lutsche mir
00:13:14.609 --> 00:13:18.919
irgendwelche Images von irgendwo aus dem
Internet rein. Klassiker sind so Ramses-
00:13:18.919 --> 00:13:24.919
der-Zweite-Debian und MySQL drei Punkt
irgendwas von neunzehnhundert-äh.
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
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
00:13:33.139 --> 00:13:37.059
euch das gleich sparen. Also ich habe hier
mal Frankenstein als Illustration
00:13:37.059 --> 00:13:41.039
gebracht. Das bringt nichts. Dann habt ihr
so ein Schrott-Projekt am Ende. Ich sehe
00:13:41.039 --> 00:13:44.409
das häufig in der Industrie, dass die
Leute alle Nachteile mitnehmen, aber die
00:13:44.409 --> 00:13:49.279
Vorteile gezielt stehen lassen.
Lachen und Applaus
00:13:49.279 --> 00:13:52.880
Häufig gerade bei so Build-Systemen und
Docker ist, dass man die Komponenten in
00:13:52.880 --> 00:13:56.209
irgendwelchen statischen Versionen hart-
codet, die halt aktuell waren, als es
00:13:56.209 --> 00:14:01.749
aufgesetzt wurde, und danach nicht mehr
geupdatet werden, ja? Also ich habe in den
00:14:01.749 --> 00:14:04.819
letzten Jahren immer mehr Leute mit
Build-Servern gesehen, die alles
00:14:04.819 --> 00:14:08.789
automatisiert bauen. Und alle Dateien
im Image haben so denselben Time-
00:14:08.789 --> 00:14:12.629
Stamp grob. Also man sieht, dass es alles
frisch gebaut wurde, aber es sind trotzdem
00:14:12.629 --> 00:14:18.399
Versionen von 2004. Das ist sehr häufig,
achtet darauf bei euch, ja? Und wenn ein
00:14:18.399 --> 00:14:22.829
Zulieferer euch Kram gibt, der vom
Build-Server kommt mit alten Versionen,
00:14:22.829 --> 00:14:27.029
dann weist ihn darauf hin. Negatives
Feedback. Das ist sonst wie so ein
00:14:27.029 --> 00:14:34.850
Rollator: bremst nur. Container hat man
für automatisiertes Deployment in
00:14:34.850 --> 00:14:39.459
deterministischem Zustand. Das ist eine
Sache, die haben fast alle verstanden.
00:14:39.459 --> 00:14:43.050
Aber was nicht so verstanden wird, ist
dieser, der Rollback ist eben auch
00:14:43.050 --> 00:14:47.239
trivial, wenn man das mit so einem Docker-
System baut. Dann klicke ich halt „Mach mal
00:14:47.239 --> 00:14:50.729
die alte Version“ und dann fällt das Image
der alten Version raus. Das ist ein
00:14:50.729 --> 00:14:54.169
Feature, das ist nicht ein Seiteneffekt,
sondern das ist einer der Gründe, warum
00:14:54.169 --> 00:14:58.849
man das überhaupt hat. Nutzt das auch.
Das ist nicht mehr… es tut nicht mehr weh,
00:14:58.849 --> 00:15:02.210
wenn man was kaputtmacht im Build,
sondern dann kann ich zurückrollen. Nicht
00:15:02.210 --> 00:15:06.509
nur im Versionierungssystem, sondern ich
kann auch einfach komplett, einen neuen
00:15:06.509 --> 00:15:10.679
Build, fällt dann halt raus. Und am besten
macht man sowas über die Mittagspause, ja?
00:15:10.679 --> 00:15:14.860
Daher vorhin der Ratschlag, im Skript
Abhängigkeiten testen. Und nicht nach zwei
00:15:14.860 --> 00:15:18.990
Stunden den Build failen lassen.
Docker ist… und Container sind
00:15:18.990 --> 00:15:22.389
eigentlich eine gute Idee. Aber die
meisten Leute nehmen nur die Nachteile
00:15:22.389 --> 00:15:29.689
mit. Komponenten kann man agil updaten.
Das muss man auch tun. Also ist hier keine
00:15:29.689 --> 00:15:32.559
schwarze Magie, die ich hier erzähle. Aber
es ist erstaunlich, wie viele Leute das
00:15:32.559 --> 00:15:37.100
nicht machen. Und der mir als Security-Typ
natürlich am wichtigsten erscheinende
00:15:37.100 --> 00:15:41.399
Aspekt bei Containern ist, dass man damit
Komponenten im Gesamtsystem isolieren kann
00:15:41.399 --> 00:15:45.970
voneinander. Dass nicht ein Typ, der
diesen einen Prozess hackt, automatisch
00:15:45.970 --> 00:15:49.949
alle anderen im Zugriff hat. Sondern die
laufen halt in ihren eigenen Containern.
00:15:49.949 --> 00:15:53.350
Aber in der Praxis sieht man, dass dann
der Monster-Container gebaut wird mit den
00:15:53.350 --> 00:16:00.300
50 Komponenten drin. Das ist nicht gut.
Also nehmt alle Vorteile mit. Richtig gut
00:16:00.300 --> 00:16:04.799
ist das natürlich erst in Kombination, ja?
Der Git hat alle Versionen und dem Build-
00:16:04.799 --> 00:16:07.830
Server kann ich eine Version zurufen und
dann fällt ein Image raus ohne
00:16:07.830 --> 00:16:13.099
Abhängigkeiten. So, wenn ihr das nicht
habt, dann benutzt ihr das nicht richtig.
00:16:13.099 --> 00:16:18.709
Ganz einfach. Das nächste Problem ist: Der
Code funktioniert nicht. Das kennen
00:16:18.709 --> 00:16:22.360
wahrscheinlich auch alle, ist ein Problem.
Was machen wir jetzt? Und die Lösung ist:
00:16:22.360 --> 00:16:27.809
Unit-Tests! Und die Umsetzung ist häufig:
ich habe hier gerade einen Bug, den fixe
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
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
00:16:35.919 --> 00:16:40.730
hoch kommt. Und ich weiß nicht, ob ihr
alle das Video hier gesehen habt. Das war
00:16:40.730 --> 00:16:43.839
so ein Automat, der erkennen sollte, ob
eine Hand drunter gehalten wurde. Und der
00:16:43.839 --> 00:16:48.199
wurde halt von Weißen gemacht. Und die
haben halt nie eine andere Hautfarbe
00:16:48.199 --> 00:16:52.560
getestet. Und da kommt dann halt nix raus.
So, das ist ein typischer Fall von „Unit-
00:16:52.560 --> 00:16:59.439
Test-Abdeckung zu gering“. Ich glaube
auch, dass hier die Perspektive die
00:16:59.439 --> 00:17:02.709
falsche ist häufig. Die Leute glauben, sie
machen Unit-Tests, damit sie wissen, dass
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
00:17:08.299 --> 00:17:12.690
und [man] sehen kann, ob es -noch- geht.
Damit ich keine Angst mehr haben muss,
00:17:12.690 --> 00:17:17.160
alten Code anzufassen. Das ist das, was
Unit-Tests euch abnehmen: die Angst, in
00:17:17.160 --> 00:17:21.830
altem Code was zu fixen. Weil ihr den
nicht komplett versteht oder so. Und
00:17:21.830 --> 00:17:26.979
je mehr Abdeckung ihr mit den Unit-Tests
habt, desto stärker ist diese Waffe.
00:17:26.979 --> 00:17:35.540
Nutzt das.
Applaus
00:17:35.540 --> 00:17:38.810
Ich muss hier ein bisschen durchgaloppieren,
weil ich zu viele Folien habe. Ich hoffe,
00:17:38.810 --> 00:17:42.249
das verzeiht ihr mir. So, das nächste
Problem sind, dass die Leute nur positive
00:17:42.249 --> 00:17:47.230
Tests haben. Die gucken: funktioniert das
hier? Und der Effekt ist normalerweise so gut
00:17:47.230 --> 00:17:51.229
wie keiner, denn die ganzen interessanten
Bugs sind in der Fehlerbehandlung, dafür
00:17:51.229 --> 00:17:55.980
braucht ihr auch Unit-Tests. Und zwar
müsst ihr eigentlich für alles, was
00:17:55.980 --> 00:18:00.640
fehlschlagen kann, einen Test haben, der
das fehlschlagen lässt. Und dann gucken,
00:18:00.640 --> 00:18:05.620
ob das immer noch funktioniert, wie es
soll. Das sind die Sachen, die am Ende
00:18:05.620 --> 00:18:09.930
über Bande woanders einen Fehler erzeugen,
ja? Irgendwie eine Memory Corruption in
00:18:09.930 --> 00:18:13.699
einem Fehlerfall, oder irgendwie „RAM wird
nicht freigegeben im Fehlerfall“. Und dann
00:18:13.699 --> 00:18:16.840
stellt sich raus: das kann man als
Angreifer triggern. Und dann habe ich einen
00:18:16.840 --> 00:18:21.320
Remote-Memory-Leak und der Prozess crasht.
Diese Art von Sachen sind völlig überflüssig
00:18:21.320 --> 00:18:26.539
und mit ordentlichen Unit-Tests abfangbar.
Also macht das. Unit-Tests sind aber kein
00:18:26.539 --> 00:18:29.389
Allheilmittel, den Eindruck möchte ich
nicht vermitteln. Selbst wenn ich 100%
00:18:29.389 --> 00:18:33.010
Unit-Test-Coverage habe, kann ich
immer noch einen Fall übersehen haben.
00:18:33.010 --> 00:18:36.691
Dennoch: das ist ein Ziel, was ihr haben
solltet. Es gibt Tools, um die Coverage zu
00:18:36.691 --> 00:18:42.840
prüfen. Nutzt diese Tools. Das ist
wichtig. So, der nächste Fall, jetzt habe
00:18:42.840 --> 00:18:45.800
ich Unit-Tests ausgerollt, ist: die
Entwickler haben Fälle vergessen zu
00:18:45.800 --> 00:18:51.370
testen, ja? Das kommt häufig vor.
Und da gibt es einen neuen Hype: Test-
00:18:51.370 --> 00:18:55.340
Driven-Development. Du schreibst erst die
Tests und dann den Code. Und da kann ich
00:18:55.340 --> 00:18:58.810
leider nichts zu sagen, weil ich das noch
nie in der Produktion gesehen habe.
00:18:58.810 --> 00:19:02.100
Ich kenne nur Leute…
00:19:02.100 --> 00:19:07.220
Lachen und Applaus
00:19:07.220 --> 00:19:10.710
Ich kenne nur Leute, die sich ganz sicher
sind, dass das total geil ist. Aber ich
00:19:10.710 --> 00:19:13.130
habe es noch nie… also wenn ihr da
irgendwie wisst, dann schreibt mir mal
00:19:13.130 --> 00:19:16.990
eine Mail, das würde mich echt
interessieren. Ja, das nächste Problem
00:19:16.990 --> 00:19:20.330
ist: wir haben hier Code, und der tut
irgendwas, aber wir haben keine Ahnung,
00:19:20.330 --> 00:19:24.380
wie das funktioniert. Und die Lösung ist
natürlich: Dokumentation! Ist auch eine
00:19:24.380 --> 00:19:28.120
gute Idee, das will ich keinem ausreden.
Aber es kommt häufig vor, Seal Team 6
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
00:19:32.860 --> 00:19:38.120
Congress-Teilnehmern nichts Neues erzählen
– das Zertifikat ist gerade abgelaufen
00:19:38.120 --> 00:19:41.770
oder das Wiki wirft Exceptions oder ist
nicht erreichbar oder so. Das ist ganz
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“.
00:19:47.350 --> 00:19:52.369
Und so: „Ja, das musst du halt bookmarken,
weil Navigation haben wir noch nicht“. Und
00:19:52.369 --> 00:19:58.739
ganz häufig gibt es auch: „Jaja, das
hier oben, das stimmt nicht mehr“.
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
00:20:04.240 --> 00:20:08.529
editieren, desto mehr fällt es unter den…
vom Tisch. Weil die Leute
00:20:08.529 --> 00:20:12.319
einfach das nicht als als wichtigen
Schritt sehen, sondern als so kleines
00:20:12.319 --> 00:20:18.409
Ding. Das muss ein richtiger Schritt im
System sein, im Produktivbetrieb, dass
00:20:18.409 --> 00:20:23.340
man sagt: „Jede Änderung wird dokumentiert,
Punkt.“ So, die nächste Idee, die man in
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,
00:20:26.520 --> 00:20:32.620
die Leute reden zu wenig miteinander“. Und
dann hat man so Großraumbüros.
00:20:32.620 --> 00:20:40.880
Lachen und Applaus
00:20:40.880 --> 00:20:43.670
Habe ich auch noch nie
funktionieren sehen.
00:20:43.670 --> 00:20:46.440
Das klappt nicht, ja? Menschen
müssen sich mal am Stück konzentrieren
00:20:46.440 --> 00:20:50.029
können. Und je mehr Unterbrechung man hat,
desto schlechter ist das. Und heute geht
00:20:50.029 --> 00:20:52.300
der Trend sogar dahin…
00:20:52.300 --> 00:20:57.810
Applaus
00:20:57.810 --> 00:21:00.879
Heute geht der Trend sogar dahin, dass die
Leute sich Slack installieren. Die
00:21:00.879 --> 00:21:05.070
plakatieren gerade in Berlin. Also, die
sich absichtlich gegenseitig unterbrechen.
00:21:05.070 --> 00:21:08.570
Ist mir völlig ein Rätsel, warum Leute
sowas tun würden. Denn nach jeder
00:21:08.570 --> 00:21:12.040
Unterbrechung braucht man so eine
Viertelstunde, bis man wieder drin ist.
00:21:12.040 --> 00:21:16.899
Und diese Chatsysteme und auch Mail-
Unterbrechungen sind darauf ausgelegt,
00:21:16.899 --> 00:21:22.130
dass man nie diese 15 Minuten schafft.
Ja, ich weiß, die Zeit ist knapp, ist gut!
00:21:22.130 --> 00:21:23.690
lacht
Lachen
00:21:23.690 --> 00:21:29.899
Meetings, ja. Meetings. Da muss ich,
glaube ich, nicht viel zu sagen.
00:21:29.899 --> 00:21:32.460
Aber der Effekt ist immer derselbe: ich
kann mich nicht konzentrieren. Und das
00:21:32.460 --> 00:21:35.920
ist ein ernstes Problem.
Da muss man aktiv gegenhalten,
00:21:35.920 --> 00:21:39.230
ja? Das ist nicht so einfach. Ich habe
jetzt überlegt: soll ich vorschlagen, die
00:21:39.230 --> 00:21:42.389
Meetings kurz zu machen? Aber das ist so,
habe ich auch nie funktionieren sehen, den
00:21:42.389 --> 00:21:46.779
Ratschlag. Alle Leute glauben immer, sie
machen ihre Meetings kurz. Funktioniert
00:21:46.779 --> 00:21:51.720
nicht. Daher sage ich: lieber selten und
One-on-One. Denn wenn man jetzt irgendein
00:21:51.720 --> 00:21:55.580
Problem klären will, und da sitzen alle
Leute aus dem Team, dann gibt es eine
00:21:55.580 --> 00:21:58.230
höhere Schwelle für den Einzelnen, zu
sagen: „Ja, da habe ich einen Fehler
00:21:58.230 --> 00:22:01.300
gemacht.“ Deswegen lieber einzeln.
00:22:01.300 --> 00:22:04.790
Applaus
00:22:04.790 --> 00:22:08.769
Niemand, niemand hat Bock darauf, sich vor
seinen Kollegen zu entblößen. Und das muss
00:22:08.769 --> 00:22:13.370
man also nicht künstlich herbeiführen. So,
jetzt kommen wir zur Security-Abteilung.
00:22:13.370 --> 00:22:16.230
Wir haben Code und er tut irgendwas, aber
wir trauen dem nicht. Was machen wir
00:22:16.230 --> 00:22:22.211
jetzt? Nächste Idee: naja okay, wir machen
erstmal die Compiler-Warnungen weg, ja?
00:22:22.211 --> 00:22:26.489
Gute Idee. Der Effekt ist – und ich war
schockiert, dass es da einen Begriff für
00:22:26.489 --> 00:22:31.290
gibt: Onion-Code. So, Onion-Code bedeutet,
dass ich so einen Chunk Legacy-Code habe,
00:22:31.290 --> 00:22:34.769
der total viele Warnungen drin hat, und
den seit fünf Jahren keiner mehr angefasst
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
00:22:39.160 --> 00:22:43.190
dann compilet der Rest immer noch mit den
ganzen Warnungen. Und die müsste ich dann
00:22:43.190 --> 00:22:47.220
fixen, damit ich den Fix einchecken kann
für den Bug. Und ich verstehe diesen Code
00:22:47.220 --> 00:22:50.669
aber nicht. Ich verstehe nur den kleinen
Teil, wo ich den Bug gefunden habe. Und
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.
00:22:55.750 --> 00:22:59.060
Und wenn das mehrere Leute machen, hat man
so eine Zwiebel. Und deswegen heißt das
00:22:59.060 --> 00:23:03.749
Onion-Code. Das ist ganz furchtbar, ja?
00:23:03.749 --> 00:23:09.590
Wenn ihr das irgendwo seht,
dann ‚burn it with fire‘!
00:23:09.590 --> 00:23:12.819
So, nächster Vorschlag: wir haben nur noch
Releases ohne offene Bugs. Das klingt auch
00:23:12.819 --> 00:23:17.280
total super. Und ich war auch mal bei
einem Kunden, der das probiert hat,
00:23:17.280 --> 00:23:22.010
und da kam dann so eine Mail:
„Mach mal deine Bugs alle zu.“ Und
00:23:22.010 --> 00:23:24.620
dann meine ich so: „Ich bin aber hier,
um Bugs aufzumachen, nicht um sie
00:23:24.620 --> 00:23:28.349
zuzumachen.“ Und dann meinte er: „Ja,
die machen wir danach wieder auf, keine
00:23:28.349 --> 00:23:36.689
Sorge.“
Lachen und Applaus
00:23:36.689 --> 00:23:40.590
Muss ich, glaube ich, nicht erläutern, ob
die wieder aufgemacht wurden oder nicht.
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
00:23:43.719 --> 00:23:47.549
an, ja, das ist leider auch teilweise ein
Antipattern. Denn was hier passiert, ist,
00:23:47.549 --> 00:23:51.689
dass die Leute so einen Blackbox-Pentest
beauftragen. Und ein Blackbox-Pentest
00:23:51.689 --> 00:23:54.700
heißt, der Tester hat keinen vollen
Zugriff auf das System, der weiß nicht,
00:23:54.700 --> 00:23:57.799
wie das funktioniert, sondern soll das in
dem Test selber rausfinden. Und dann
00:23:57.799 --> 00:24:02.259
passiert sowas hier. Und was mich an der
Stelle am meisten beeindruckt hat, ist,
00:24:02.259 --> 00:24:07.480
dass es dieses Bild schon gab. Das habe
ich jetzt nicht gemacht. So, das ist
00:24:07.480 --> 00:24:12.089
leider üblich. Man testet nicht den Code,
sondern man testet den Pentester. Und ich
00:24:12.089 --> 00:24:15.349
als Pentester habe jetzt natürlich… könnte
jetzt sagen: „Ja, ist mir doch egal, wen
00:24:15.349 --> 00:24:19.579
die da testen, solange ich bezahlt werde.“
Aber ich habe da so einen Moralkodex. Ich
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
00:24:23.072 --> 00:24:27.462
Seiten Scheiße. Macht das nicht. Ja,
Pentests. Ich sage, das ist ein
00:24:27.462 --> 00:24:31.719
Compliance-Problem, dass die Leute alle
aus Compliance-Gründen Pentests machen.
00:24:31.719 --> 00:24:35.300
Und das ist eigentlich an sich schon ein
furchtbares Zeichen, dass wir die Security
00:24:35.300 --> 00:24:38.930
nicht hinkriegen, sondern Compliance
brauchen, um uns dazu zu bringen, dass wir
00:24:38.930 --> 00:24:44.989
doch Security machen. Wir sollten uns alle
schämen! Fuzzing ist auch so ein Ding. Das
00:24:44.989 --> 00:24:49.500
wird gerne gemacht. Fuzzing heißt, dass
ich zufällige Eingaben generiere und gegen
00:24:49.500 --> 00:24:52.959
meinen Endpunkt werfe und gucke, ob der
platzt oder nicht. Und das ist
00:24:52.959 --> 00:24:56.929
erschütternd erfolgreich, ja? Das
funktioniert. Und ich habe mal erlebt,
00:24:56.929 --> 00:24:59.731
dass sie gesagt haben: „Nee, den Code
hier, den musst du nicht testen, den haben
00:24:59.731 --> 00:25:04.100
wir schon zu Tode gefuzzt. Seit Monaten
läuft unsere Fuzzing-Farm.“ Und da stellt
00:25:04.100 --> 00:25:06.999
sich dann heraus: die haben zwar
Milliarden von Test-Cases geprüft. Aber
00:25:06.999 --> 00:25:11.809
das war immer derselbe.
Lachen
00:25:11.809 --> 00:25:16.000
Total super. Und häufig ist Fuzzing so ein
Feigenblatt, womit dann andere Maßnahmen
00:25:16.000 --> 00:25:18.470
nicht gemacht werden, weil wir haben doch
schon gefuzzt, und das ist auch in
00:25:18.470 --> 00:25:21.989
Ordnung, ja? Also ich habe nichts gegen
Fuzzing an sich, denn es funktioniert
00:25:21.989 --> 00:25:31.610
leider. Aber es darf kein Hindernis dafür
sein, andere wichtige Maßnahmen zu machen.
00:25:31.610 --> 00:25:35.230
Das ist ein generelles Problem, was ich
häufiger sehe, dass, wenn das Management
00:25:35.230 --> 00:25:39.579
die Wahl hat zwischen einer Maßnahme, die
wahrscheinlich funktioniert, aber keine
00:25:39.579 --> 00:25:43.379
Metriken abwirft, und einer Maßnahme, die
wahrscheinlich nicht funktioniert, aber
00:25:43.379 --> 00:25:48.199
Metriken abwirft, dass immer die mit den
Metriken gemacht wird. Management liebt
00:25:48.199 --> 00:25:51.900
qualifizierbare Geschichten, wo irgend…
quantifizierbare Geschichten, wo
00:25:51.900 --> 00:25:56.279
irgendeine Zahl rausfällt. Und das geht
häufig nach hinten los, ja? Ich habe also
00:25:56.279 --> 00:26:01.630
mal so ein… das war ein wirklich
schockierendes Erlebnis für mich. Ich bin,
00:26:01.630 --> 00:26:05.820
ich sage mal preiswert, aber nicht billig,
ja, also meine Tagessätze. – Ich weiß, ich
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
00:26:11.160 --> 00:26:15.360
Hause.“ Also ich wurde trotzdem bezahlt,
ja? Haben gesagt: „Geh mal nach Hause.“
00:26:15.360 --> 00:26:19.730
Und ich so: „Wie jetzt?“ „Ja, ist warm
heute.“ Meinte ich so: „Was?“ „Ja die
00:26:19.730 --> 00:26:23.110
Klimaanlage reicht für das Fuzzing-Lab
oder die Consultants.“
00:26:23.110 --> 00:26:31.720
Lachen und Applaus
Ja. Gut. Das nächste Problem, das ist so
00:26:31.720 --> 00:26:35.580
ein bisschen schwierig. Aber es ist mir
sehr wichtig, weil das so gerade im Kommen
00:26:35.580 --> 00:26:40.650
ist. Die Coder sind überfordert. Und dann
sagt man: wir brauchen irgendeinen soliden
00:26:40.650 --> 00:26:43.820
Ansatz. Thread-Modeling! Das ist gerade
im Kommen. Und das ist eine gute
00:26:43.820 --> 00:26:47.520
Geschichte, aber es wird häufig
missverstanden. Thread-Modeling, der
00:26:47.520 --> 00:26:50.890
übliche Ansatz ist, dass man sagt: jedes
Team macht ein Thread-Model für den Code.
00:26:50.890 --> 00:26:56.419
Das ist gut. Ja? Aber häufig macht dann
der Feature-Owner oder Projektmanager
00:26:56.419 --> 00:27:00.350
mit dem Dokumentationsteam zusammen, füllt
irgendwelche Formulare aus, und die
00:27:00.350 --> 00:27:05.049
Developer sind überhaupt nicht betroffen.
Und das ist ein krasser Fehler. Denn beim
00:27:05.049 --> 00:27:09.079
Thread-Modeling geht es nicht um das
Papier am Ende. Das ist kein Zertifikat.
00:27:09.079 --> 00:27:13.549
Sondern es geht um den Weg zum Papier. Es
geht darum, dass die Entwickler mal aus
00:27:13.549 --> 00:27:17.229
der Sicht des Angreifers versuchen, auf
ihren Code zu gucken, dass sie verstehen,
00:27:17.229 --> 00:27:21.239
was da Angriffsoberfläche ist, dass sie
sehen, wo die Sachen sind, auf die man
00:27:21.239 --> 00:27:25.099
aufpassen muss, welche Angriffe denkbar
sind. Wenn jemand anderes das Thread-Model
00:27:25.099 --> 00:27:29.720
macht, das hätte man sich auch sparen
können, ja? Also: Thread-Model ist gut,
00:27:29.720 --> 00:27:34.230
aber das müssen die Entwickler machen. Wir
sind fast durch. Ich habe noch ein paar
00:27:34.230 --> 00:27:37.060
allgemeine Ratschläge, weil ich mir
dachte: ich kann euch hier nicht so
00:27:37.060 --> 00:27:41.819
deprimiert nach Hause gehen lassen. Aus
Sicht des Management ist aus meiner Seite
00:27:41.819 --> 00:27:44.800
ganz wichtig, dass man eine Fehlerkultur
etabliert. Das heißt: niemand wird
00:27:44.800 --> 00:27:48.389
bestraft für Bugs. Denn sonst verstecken
die Leute Bugs, und das ist noch
00:27:48.389 --> 00:27:51.610
schlechter, ja? Man muss Leute belohnen,
…
00:27:51.610 --> 00:27:58.231
Applaus
Man muss Leute belohnen, wenn sie
00:27:58.231 --> 00:28:02.239
einen Bug finden und fixen. Aber nicht
mit Geld belohnen, sondern mit Ruhm und
00:28:02.239 --> 00:28:06.860
Ehre. Ich schlage immer vor, einmal die
Woche, irgendwie Freitag ab 4 oder so,
00:28:06.860 --> 00:28:12.759
macht man so ein All-Hands-Meeting, wo –
wenn die Leute wirklich was Anderes
00:28:12.759 --> 00:28:17.069
vorhaben, müssen sie nicht hingehen, also
kein Zwang – aber wo dann die alten
00:28:17.069 --> 00:28:22.159
Hasen ihre schönsten Bugs erklären, ja?
Damit es als etwas Positives gesehen wird,
00:28:22.159 --> 00:28:25.830
einen Bug zu finden, und damit die Jungen
was dabei lernen. Das ist eine gute Sache,
00:28:25.830 --> 00:28:29.089
das kann ich empfehlen. Das funktioniert
auch gut, und das bringt auch das Team
00:28:29.089 --> 00:28:35.009
zusammen. Und es nimmt so diesen Rockstar-
Status weg, der auch nur schadet. So, die
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,
00:28:38.870 --> 00:28:42.650
der den Code geschrieben hat. Es gibt
große Firmen, die teilweise ein zweites
00:28:42.650 --> 00:28:46.729
Team dafür haben, Sicherheits-Bugs zu
fixen. Und dann kriegt der Typ, der das
00:28:46.729 --> 00:28:49.320
programmiert hat, überhaupt nicht mit,
dass er die ganze Zeit schlechten Code
00:28:49.320 --> 00:28:52.880
programmiert. Der zieht dann am besten
noch so von Team zu Team, hinterlässt
00:28:52.880 --> 00:28:57.409
überall so Tretminen. Das ist wichtig,
dass es Feedback gibt. Und zwar nicht als
00:28:57.409 --> 00:29:00.650
Strafe, sondern damit die Leute merken,
wenn sie Fehler machen, ja? Menschen
00:29:00.650 --> 00:29:04.010
lernen aus ihren Fehlern. Dafür muss man
verstehen, wenn man einen Fehler gemacht
00:29:04.010 --> 00:29:08.199
hat. Und das ist die, wo… komme ich
zurück zu dieser Meeting-Kultur. Wenn man
00:29:08.199 --> 00:29:11.680
ein Meeting hat und sagt: „Du hast hier
aber Scheiße gemacht“, dann macht man den
00:29:11.680 --> 00:29:15.640
vor dem ganzen Team nackig. Das hilft
überhaupt nicht, ja? Man… es ist auch
00:29:15.640 --> 00:29:19.369
eine Kulturkreis-Frage. Manche
Kulturkreise können damit besser umgehen
00:29:19.369 --> 00:29:24.980
als andere. Aber es gibt eben viele Leute,
die haben ein starkes Problem damit, dass
00:29:24.980 --> 00:29:28.160
ihnen gesagt wird: „Du hast einen Fehler
gemacht“, ja? Weil das, in Japan zum
00:29:28.160 --> 00:29:32.190
Beispiel ist es sehr wichtig, dass man der
Firma hilft und nicht gesehen wird, wie
00:29:32.190 --> 00:29:36.281
man irgendwie an irgendwas schuld ist.
Also das ist schwierig, so etwas
00:29:36.281 --> 00:29:40.209
aufzubauen. Aber das ist sehr wichtig.
Fehler sind nicht schlecht, sondern aus
00:29:40.209 --> 00:29:46.040
den Fehlern kann man lernen, ja? Fehler
sind gut. Dann finde ich, dass die Firma
00:29:46.040 --> 00:29:50.520
Werte kommunizieren sollte. Werte wie:
uns ist der Code wichtiger, die Güte des
00:29:50.520 --> 00:29:54.789
Codes ist wichtiger als die Quantität, ja?
Es kommt nicht darauf an, hier mehr Kram
00:29:54.789 --> 00:29:59.619
dran zu tun, sondern es kommt darauf an,
dass wir, wenn wir was geschrieben haben,
00:29:59.619 --> 00:30:02.820
da auch noch einmal darauf zurückkommen
später, ja? Wenn wir was dazugelernt
00:30:02.820 --> 00:30:07.929
haben, dass wir das auf den alten Code
anwenden. Und damit das stressfrei machbar
00:30:07.929 --> 00:30:12.600
ist, braucht man ordentliche Unit-Tests.
So haben wir dann so einen Kreisschluss.
00:30:12.600 --> 00:30:15.910
Die Anekdote, die ich hier erzählen
wollte, war, dass ich mit einem Freund
00:30:15.910 --> 00:30:20.690
einen Job hatte. Und da war… Teil von dem
Problem war ein User-Interface. Und da
00:30:20.690 --> 00:30:24.110
hatten wir beide überhaupt keine Ahnung
von. Und der Freund meinte dann ganz
00:30:24.110 --> 00:30:27.980
locker: „Ja lass uns das in Qt machen.“
Und ich meinte so: „Wir haben beide keine
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
00:30:30.990 --> 00:30:34.319
Resümee stehen, ja? Das muss… in meinem
Lebenslauf sieht das gut aus.“ Das ist
00:30:34.319 --> 00:30:37.349
schon ein paar Jahre her. Aber was ich
sagen will: wenn die Firma den Leuten
00:30:37.349 --> 00:30:41.210
nicht die Zeit gibt, Sachen zu lernen,
dann lernen sie das in Projekten der
00:30:41.210 --> 00:30:45.390
Firma, und die werden dann Scheiße.
00:30:45.390 --> 00:30:55.130
Applaus
00:30:55.130 --> 00:30:58.450
Was man auch häufiger sieht, ist, dass das
Management glaubt, sie müsste die
00:30:58.450 --> 00:31:02.600
Architektur der Software vorgeben, oder
welche Datenbank verwendet wird oder so.
00:31:02.600 --> 00:31:05.480
Und das ist eigentlich auch immer eine
schlechte Idee. Denn entweder die
00:31:05.480 --> 00:31:08.659
Architektur ist offensichtlich, dann hilft
es nichts. Oder sie ist nicht
00:31:08.659 --> 00:31:11.060
offensichtlich, dann sind die Ratschläge
wahrscheinlich falsch, weil wir das
00:31:11.060 --> 00:31:14.730
Problem noch nicht wirklich verstanden
haben. Also das ist auch eine Sache, da
00:31:14.730 --> 00:31:18.490
sollte sich das Management
zurücknehmen an der Stelle.
00:31:18.490 --> 00:31:23.550
Applaus
Und hier noch so ein bisschen Selbsthilfe
00:31:23.550 --> 00:31:28.409
für Entwickler. Ist die letzte Folie, ganz
entspannt bleiben. Der Druck kommt immer
00:31:28.409 --> 00:31:32.690
von euch selbst. Das Management kann viel
erzählen, ja? Deadline hier, Deadline da.
00:31:32.690 --> 00:31:37.330
Lasst euch da nicht dazu bringen,
Überstunden zu fahren. Immer schön um 9
00:31:37.330 --> 00:31:44.280
kommen, um 5 nach Hause gehen. Also…
Applaus
00:31:44.280 --> 00:31:49.800
Wenn unrealistische Anforderungen
reinkommen, dann müsst ihr da ganz ehrlich
00:31:49.800 --> 00:31:52.910
sein und sagen: „Das wird wahrscheinlich
nicht klappen. Ich nehme jetzt euer Geld
00:31:52.910 --> 00:31:56.729
und arbeite daran. Aber ich sage euch
jetzt: das wird nix, ja?“ Immer schön
00:31:56.729 --> 00:32:00.460
Paper-Trail hinterlassen, dass das nichts
wird und man es rechtzeitig gesagt hat.
00:32:00.460 --> 00:32:03.230
Man kann dann dran arbeiten, weil viele
von euch werden wahrscheinlich die Kohle
00:32:03.230 --> 00:32:07.110
brauchen, aber ehrlich sein, nicht so tun,
als wenn wir das mit ein paar irgendwie
00:32:07.110 --> 00:32:10.920
die-Nacht-durchgemacht am Ende noch
reißen können. Das ist besonders in der
00:32:10.920 --> 00:32:15.600
Spielebranche ein riesiges Problem, dass
die Leute total Burnout kriegen. Man muss
00:32:15.600 --> 00:32:19.460
das verstehen mit dem Management wie ein
gegenseitiges Training, ja? Wenn ich dem
00:32:19.460 --> 00:32:22.969
Management so etwas durchgehen lasse,
dann zeige ich ihnen: das ist die neue
00:32:22.969 --> 00:32:25.609
Baseline, ja? Das erwarten die ab dann.
00:32:25.609 --> 00:32:27.570
Herald: Soll ich mir einen Stuhl holen,
damit ich mich daneben setze?
00:32:27.570 --> 00:32:28.939
Fefe: Kannst du machen,
das ist die letzte Folie.
00:32:28.939 --> 00:32:31.219
Herald: Okay.
Fefe: Ganz ruhig!
00:32:31.219 --> 00:32:33.769
So, und der letzte Satz,
den ich habe: Zeit ist… muss man sich
00:32:33.769 --> 00:32:36.240
selber nehmen, ja?
Ich habe zwar gerade gesagt…
00:32:36.240 --> 00:32:42.059
Lachen und Applaus
00:32:42.059 --> 00:32:50.299
Herald: Raus mit dir!
weiter Applaus
00:32:50.299 --> 00:32:52.910
Ich habe zwar gerade dem Management
empfohlen, euch Zeit zu geben,
00:32:52.910 --> 00:32:56.020
aber wenn ihr darauf wartet,
das wird nichts.
00:32:56.020 --> 00:32:59.540
Lachen
So, ich fürchte, die Fragezeit ist schon
00:32:59.540 --> 00:33:02.830
vorbei, oder?
Herald: Jo.
00:33:02.830 --> 00:33:13.519
Lachen und Applaus
00:33:13.519 --> 00:33:17.269
Das Beeindruckende ist ja wirklich:
die sind alle da geblieben, und da ist
00:33:17.269 --> 00:33:22.380
nicht einer vom Stuhl gefallen.
Fefe: Ja! lacht
00:33:22.380 --> 00:33:27.749
Herald: Vielen, vielen Dank! Ausgänge
sind beide offen. Das war’s von Fefe.
00:33:27.749 --> 00:33:30.339
Hier noch mal ein Applaus für ihn bitte!
00:33:30.339 --> 00:33:38.093
Applaus
00:33:38.093 --> 00:33:54.417
Abspannmusik
00:33:54.417 --> 00:33:59.301
Untertitel erstellt von c3subtitles.de
im Jahr 2018