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