1 00:00:00,000 --> 00:00:15,720 *34c3 preroll music* 2 00:00:15,720 --> 00:00:20,940 Herald: Der Fefe hatte mich gebeten, mich kurz zu halten, weil, er hat Angst, 3 00:00:20,940 --> 00:00:26,740 dass der Talk nicht in die 30 Minuten passt. Von daher gebe ich jetzt mal Gas und 4 00:00:26,740 --> 00:00:29,909 sage: „Antipatterns und Missverständnisse in der Software-Entwicklung“! 5 00:00:29,909 --> 00:00:34,049 Und wie sagte jemand gestern? „Ach Fefe! Das ist doch der mit der Kolumne 6 00:00:34,049 --> 00:00:37,870 beim ehemaligen Nachrichtenmagazin!“ Here we go! 7 00:00:37,870 --> 00:00:47,040 *Applaus* 8 00:00:47,040 --> 00:00:50,691 Fefe: Hallo hallo. Hallo hallo. Ja, ja vielen Dank, dass ihr so zahlreich 9 00:00:50,691 --> 00:00:53,350 erschienen seid. Ein bisschen zahlreicher, als ich gedacht habe. Nächstes Mal mache 10 00:00:53,350 --> 00:00:59,260 ich doch lieber parallel zu Minkorrekt wieder. Es geht um Antipatterns. 11 00:00:59,260 --> 00:01:04,170 Antipatterns sind Sachen, die man macht, die man häufig macht, die populäre 12 00:01:04,170 --> 00:01:07,820 Maßnahmen sind, um ein Problem zu lösen, die dann aber entweder gar nicht 13 00:01:07,820 --> 00:01:13,680 funktionieren oder nach hinten losgehen. Und ich habe mir gedacht, beim Congress 14 00:01:13,680 --> 00:01:17,840 gibt es immer so schöne Streitereien um das Motto. Da mache ich auch mal ein Motto. 15 00:01:17,840 --> 00:01:20,350 Und das hier ist so ein Motto, was ich sehr profunde finde, und wo ihr 16 00:01:20,350 --> 00:01:25,850 hoffentlich im Laufe des Vortrags sehen werdet, warum das das Motto ist. Ja, „wer 17 00:01:25,850 --> 00:01:31,530 lesen kann, aber es nicht tut, hat keinen Vorteil dem gegenüber, der das nicht kann“. 18 00:01:31,530 --> 00:01:36,330 Die Struktur des Vortrags… *Applaus* 19 00:01:36,330 --> 00:01:41,720 Die Struktur des Vortrags will ich an einem Beispiel kurz umreißen. 20 00:01:41,720 --> 00:01:45,640 Es geht immer damit los, dass wir ein Problem haben. 21 00:01:45,640 --> 00:01:50,380 Dann geht immer Seal Team 6 los und hackt irgendwas. 22 00:01:50,380 --> 00:01:53,280 Also denkt euch hier ein Team von Spezialexperten. Ja ich will jetzt nicht 23 00:01:53,280 --> 00:01:58,190 die Seals beleidigen, bestimmt auch alles nette Leute. Und dann kommt eine Umsetzung, 24 00:01:58,190 --> 00:02:02,780 da geht es meistens in die Hose. Und dann haben wir einen Effekt, und 25 00:02:02,780 --> 00:02:08,390 hoffentlich, hoffentlich eine Erkenntnis gewonnen. Ich habe mir gedacht, wir 26 00:02:08,390 --> 00:02:11,840 versuchen mal so eine interaktive Komponente. Und zwar wenn man sich so 27 00:02:11,840 --> 00:02:15,920 Übertragungen aus dem britischen Parlament ansieht, dann gibt es immer so ein 28 00:02:15,920 --> 00:02:19,372 Gemurmel, wenn die Leute zustimmen. Und ich dachte mir, wenn ich sage, „Hebt mal 29 00:02:19,372 --> 00:02:23,190 den Arm, wenn euch das mal passiert ist“, dann haben die Leute vielleicht Angst, auf 30 00:02:23,190 --> 00:02:26,690 dem Stream zu landen und sich zu outen. Deswegen dachte ich, wir murmeln mal. Also 31 00:02:26,690 --> 00:02:30,020 wenn einer von euch sich bei einem Muster wiedererkennt, könnt ihr mal versuchen. 32 00:02:30,020 --> 00:02:34,210 Wir gucken mal, ob das klappt. Ja, vielleicht hört man das dann. Okay. 33 00:02:34,210 --> 00:02:38,690 Also, erstes Problem. Dieses Bild, ich möchte das gleich dazusagen, 34 00:02:38,690 --> 00:02:44,680 *Lachen* ist mir gespendet worden. 35 00:02:44,680 --> 00:02:48,339 Ich liefere hier keine Kunden ans Messer, und es geht nur um Anekdoten. 36 00:02:48,339 --> 00:02:52,599 Also wer sich glaubt, wiederzuerkennen, liegt wahrscheinlich falsch. 37 00:02:52,599 --> 00:02:56,040 So, das ist ein typisches Problem in der Software-Entwicklung: 38 00:02:56,040 --> 00:03:00,010 die Versionierung von und die Backups von alten Versionen aufzuheben. 39 00:03:00,010 --> 00:03:05,220 Das ist hier, ich hoffe, ihr habt das gesehen oben in der Ecke, das ist ein USB-Stick. 40 00:03:05,220 --> 00:03:07,950 Und die typische Idee ist: Wir machen jetzt mal ein Versionierungssystem! 41 00:03:07,950 --> 00:03:11,800 Und das ist eine gute Idee. Die Umsetzung ist dann gewöhnlich: 42 00:03:11,800 --> 00:03:14,820 der, der gerade ein akutes Problem hat, bastelt schnell was, 43 00:03:14,820 --> 00:03:18,550 und dann kriegt man so ein Git. Und Git ist eigentlich gut, aber man hat halt 44 00:03:18,550 --> 00:03:22,960 nicht nur Git, sondern man hat dann noch so ein paar andere Versionierungssysteme, 45 00:03:22,960 --> 00:03:27,129 und da gehen dann die Probleme los. Ja also, ich habe mal einen, ich habe mal so 46 00:03:27,129 --> 00:03:30,070 einen Kunden gehabt, die meinten: „Ist im Git“, und dann meinte der Typ daneben: 47 00:03:30,070 --> 00:03:33,009 „Ja, musst noch sagen, in welchem“. Also das kommt vor. 48 00:03:33,009 --> 00:03:36,379 *Lachen* Ein anderer Effekt, den man häufig 49 00:03:36,379 --> 00:03:40,770 sieht, ist, dass jeder überall einchecken darf. Und das führt dann zu so Sachen wie: 50 00:03:40,770 --> 00:03:45,540 man meldet als Bug so was wie: „In dem Image sind aber noch set-UID-Binaries“ 51 00:03:45,540 --> 00:03:48,540 oder sowas. Und dann machen die die alle weg, und dann installiert man die nächste 52 00:03:48,540 --> 00:03:52,040 Version, und dann sind wieder welche, und dann sagt der Typ: „Ja, ich habe die zwar 53 00:03:52,040 --> 00:03:55,850 alle weg gemacht, aber hat halt ein Developer wieder rein gemacht“. 54 00:03:55,850 --> 00:04:00,270 Also Versionierung reicht noch nicht. Da muss man noch mehr machen. 55 00:04:00,270 --> 00:04:04,470 Überhaupt die Idee, dass Leute Binaries einchecken, ist eine ganz schlechte. 56 00:04:04,470 --> 00:04:07,010 Das findet man immer wieder. Ich rede jetzt hier nicht von png 57 00:04:07,010 --> 00:04:11,140 oder irgendwie ein mpeg von einer Webseite oder sowas, sondern so eine Library oder 58 00:04:11,140 --> 00:04:14,750 ein Executable. Das sollte man eigentlich nicht tun. 59 00:04:14,750 --> 00:04:17,790 Es gibt ganz wenige Ausnahmen. Wenn ihr eine von den Ausnahmen habt, 60 00:04:17,790 --> 00:04:21,400 wisst ihr es, und ansonsten macht es nicht! 61 00:04:21,400 --> 00:04:23,790 Das hier ist jetzt natürlich überspitzt, aber so ähnlich habe ich das schon 62 00:04:23,790 --> 00:04:27,410 mal gesehen, dass Leute verschiedene Versionen einchecken, aber nicht 63 00:04:27,410 --> 00:04:31,210 verstanden haben, was eigentlich die Aufgabe von so einem Versionierungssystem ist. 64 00:04:31,210 --> 00:04:36,910 Das ist auch nicht gut, macht das nicht! 65 00:04:36,910 --> 00:04:41,330 Ich habe dann immer so einen Ratschlag am Ende von den jeweiligen Antipatterns. 66 00:04:41,330 --> 00:04:44,710 Und mein Ratschlag für Versionierungssysteme ist: Git ist schon in Ordnung. 67 00:04:44,710 --> 00:04:48,240 Ich bin mir der Ironie bewusst, dass meine eigene Software im Moment als CVS 68 00:04:48,240 --> 00:04:51,490 im Internet ist. Das hat historische Gründe! 69 00:04:51,490 --> 00:04:57,852 *Lachen und Applaus* 70 00:04:57,852 --> 00:05:02,562 Patches hält man am besten klein, damit man sie einzeln anfassen kann, 71 00:05:02,562 --> 00:05:05,080 wenn sie nicht sauber applyen. Das ist ein Riesenproblem, wenn jemand 72 00:05:05,080 --> 00:05:07,710 so einen Megabyte-Patch abliefert. Deswegen macht das nicht. 73 00:05:07,710 --> 00:05:12,170 Wenn ihr größere Sachen vorbereiten müsst, dann macht das nicht als einen großen 74 00:05:12,170 --> 00:05:15,790 Patch, sondern nehmt einen eigenen Branch dafür. So ein Versionierungssystem will 75 00:05:15,790 --> 00:05:20,960 euch helfen. Also beschäftigt euch mit den Features, die sie euch bieten. 76 00:05:20,960 --> 00:05:24,660 Wenn man Annahmen hat, über, welche APIs verfügbar sind, oder welche Versionen von 77 00:05:24,660 --> 00:05:29,190 Komponenten drin sein sollen, sollte man das im Build in einem Skript checken. 78 00:05:29,190 --> 00:05:32,709 Und nicht erst anfangen zu bauen, und nach zwei Stunden abbrechen, weil irgendwas 79 00:05:32,709 --> 00:05:36,210 nicht geklappt hat. Sowas möglichst vorher testen, damit es schnell failt, 80 00:05:36,210 --> 00:05:39,280 damit man schnell reagieren kann. 81 00:05:39,280 --> 00:05:42,660 Es gibt häufig so die Idee in Firmen, dass man verschiedene Abteilungen hat und jede 82 00:05:42,660 --> 00:05:47,470 hat ihr eigenes Versionierungssystem oder ihr eigenes Repository. Und das kann 83 00:05:47,470 --> 00:05:52,159 funktionieren, aber es ist sehr selten, ja? Häufig, der… der… 84 00:05:52,159 --> 00:05:55,980 die Sache, die stimmen muss, damit es klappt, ist, dass die APIs stabil sind. 85 00:05:55,980 --> 00:05:59,200 Und erfahrungsgemäß glauben alle, dass ihre APIs stabil bleiben werden, und 86 00:05:59,200 --> 00:06:04,820 sie sind es dann aber nie. Also wenn ihr das vermeiden könnt, macht das nicht. 87 00:06:04,820 --> 00:06:07,820 So, das nächste Problem ist: die Bugs fallen immer unter den Tisch, werden 88 00:06:07,820 --> 00:06:11,450 vergessen, gefixt zu werden. Und die offensichtliche Lösung ist: 89 00:06:11,450 --> 00:06:15,910 wir machen so einen Bugtracker. Umsetzung ist natürlich wie immer Seal 90 00:06:15,910 --> 00:06:20,840 Team 6. Und der Effekt, der sich ganz schnell einstellt, ist, dass man merkt, 91 00:06:20,840 --> 00:06:25,660 man hat ganz viele Bugs. Und das ist dann gleich das nächste Problem: 92 00:06:25,660 --> 00:06:29,470 wir haben so viele Bugs, was machen wir jetzt? 93 00:06:29,470 --> 00:06:32,609 Eine Sache, die ich inzwischen als Antipattern sehe, ist: Priorisieren von 94 00:06:32,609 --> 00:06:37,510 Bugs. Ja, so eine übliche Umsetzung ist: man hat sowas wie „Severity: Blocker“ 95 00:06:37,510 --> 00:06:41,760 oder das ist ein Security-Bug – das soll hier eine Checkbox sein. Und der Effekt 96 00:06:41,760 --> 00:06:45,670 davon ist, dass alle anderen Bugs liegen bleiben. Das kann man immer und immer 97 00:06:45,670 --> 00:06:49,830 wieder beobachten. Also die… der eigentliche… was ich so beobachte, der, 98 00:06:49,830 --> 00:06:52,759 der Effekt, der die meisten Bugs tötet, ist, wenn eine Komponente einfach 99 00:06:52,759 --> 00:06:55,930 abgeschafft wird. Und dann kann man alles schließen in der Komponente. 100 00:06:55,930 --> 00:06:59,550 Dass tatsächlich mal sowas weggeht, gibt es nicht. 101 00:06:59,550 --> 00:07:04,240 *Applaus* Es gibt ein schönes Wort dafür, wo mir 102 00:07:04,240 --> 00:07:09,419 jetzt die Übersetzungsteams bisschen leid tun, nämlich Bug-Welle, im Sinne von einer 103 00:07:09,419 --> 00:07:14,040 Bugwelle vor so einem Tanker. Ich versuche das gerade mal zu etablieren, als Begriff. 104 00:07:14,040 --> 00:07:18,080 Ich finde den nämlich sehr schön. So, also jetzt haben wir ganz viele offene Bugs, 105 00:07:18,080 --> 00:07:22,300 was machen wir denn jetzt? Nächstes Problem. Und eine Idee, die häufig kommt, 106 00:07:22,300 --> 00:07:27,320 und die auch erstmal total super klingt, ist, dass man bug-freien Code belohnt. 107 00:07:27,320 --> 00:07:31,389 Und zwar am besten mit so einem Bonus, am besten in Geld. Wenn euer Team keine 108 00:07:31,389 --> 00:07:36,780 offenen Bugs hat, dann werdet ihr belohnt. Und das führt eben dazu, das ist mir mal 109 00:07:36,780 --> 00:07:40,849 passiert, dass ich so eine Mail gekriegt habe von einem Typ, wo ich ein paar Bugs 110 00:07:40,849 --> 00:07:45,290 gefilet habe, und der kommt und meint: „Du Arschloch, jetzt ist mein Bonus weg. Ich 111 00:07:45,290 --> 00:07:50,560 kann meine Hypothek nicht abzahlen!“ Und da wusste ich dann auch erstmal nicht 112 00:07:50,560 --> 00:07:55,319 direkt, was ich dem sagen soll. Der hat das dann selbst gelöst, indem er alle Bugs 113 00:07:55,319 --> 00:07:59,920 zugemacht hat und zwar mit NOTABUG. *Lachen* 114 00:07:59,920 --> 00:08:02,610 Hat mir natürlich versprochen, dass die trotzdem alle gefixt werden. Aber das 115 00:08:02,610 --> 00:08:07,030 könnt ihr euch ja vorstellen, wie gut das klappt. Also sowas ist sehr… ist sehr mit 116 00:08:07,030 --> 00:08:11,539 Vorsicht zu genießen. Reward- und Incentives-Sachen am besten nicht mit 117 00:08:11,539 --> 00:08:16,809 Geld. Es gibt auch ein Anti-Antipattern dazu. Nämlich habe ich mal erlebt, dass 118 00:08:16,809 --> 00:08:20,990 jemand alle Bugs im Code gefixed hat, aber im Bugtracker waren die noch offen. Und 119 00:08:20,990 --> 00:08:23,920 dann habe ich nicht verstanden, bin hingegangen, und dann hat er mir erklärt: 120 00:08:23,920 --> 00:08:26,330 „Ja, die brauchen mich ja nicht mehr, wenn die Bugs zu sind.“ 121 00:08:26,330 --> 00:08:29,090 *Lachen und Applaus* Der hat halt gesehen, hat halt gesehen, um 122 00:08:29,090 --> 00:08:34,629 ihn rum die Kollegen sind alle nach Indien abgeschoben worden, die Projekte, und 123 00:08:34,629 --> 00:08:37,779 hat sich gedacht: „Na, die lass ich lieber offen, die Bugs, dann werde ich hier noch 124 00:08:37,779 --> 00:08:41,639 ein paar Monate bezahlt.“ Das hat mir echt, das fand ich echt atemberaubend. 125 00:08:41,639 --> 00:08:45,369 Da habe ich so ein paar Tage schlecht geschlafen. Weil das ist ja schon… was 126 00:08:45,369 --> 00:08:49,040 für ein Selbstbild hat der denn, wenn er glaubt, irgendwie diese, diese Einträge im 127 00:08:49,040 --> 00:08:53,630 Bugtracker halten ihn da am Leben? Ganz furchtbar. Aber das gibt es in kleineren 128 00:08:53,630 --> 00:09:00,040 Ausmaßen häufiger, dass Leute Bugs offen lassen, weil sie wissen: wenn die Bugs weg 129 00:09:00,040 --> 00:09:05,050 sind, dann kommt der Chef mit der nächsten To-Do-Liste. Und der einzige Weg, mal eine 130 00:09:05,050 --> 00:09:08,830 Woche Luft zu haben, ist einfach, die Bugs nicht zu fixen. Das gibt es häufiger, 131 00:09:08,830 --> 00:09:12,429 achtet mal darauf in eurer Firma, ob ihr das auch sehen könnt. Ich würde fast 132 00:09:12,429 --> 00:09:18,599 wetten: ja. Das ist ein häufiges Pattern. Das ist auch ein Klassiker hier. Man hat 133 00:09:18,599 --> 00:09:22,470 ein tolles Projekt, und das ist wunderbar, aber es funktioniert nur auf dem Rechner 134 00:09:22,470 --> 00:09:26,889 vom Entwickler. Und die Idee ist: man hat jetzt einen Build-Server, ja? Wir haben 135 00:09:26,889 --> 00:09:29,779 jetzt einen Build-Server, da wird gebaut, das ist eine neutrale Umgebung, 136 00:09:29,779 --> 00:09:33,709 alles super. Seal Team 6 bastelt kurz was, und das sieht auch echt geil aus, ja? 137 00:09:33,709 --> 00:09:38,269 Hier, so Drohnen-assistierte Baugeschichten. Aber übliche Sachen, die 138 00:09:38,269 --> 00:09:42,540 halt fehlschlagen, ist, dass dieser Build- Server von dem Team ist, und baut halt den 139 00:09:42,540 --> 00:09:47,160 Code von dem Team. Und die anderen Sachen werden aus irgendwelchen antiken Snapshots 140 00:09:47,160 --> 00:09:50,939 von anderen Leuten reingezogen. Oder was ich auch mal gesehen habe: dass Libraries 141 00:09:50,939 --> 00:09:56,019 dann so per SMB da reingelinkt werden. Und das ist natürlich totale Scheiße, ja? 142 00:09:56,019 --> 00:10:01,719 Aber das passiert, so was passiert. Eine häufige Sache, die man auch sieht, ist, 143 00:10:01,719 --> 00:10:04,760 dass man so einen Build-Server hat, aber da muss dann jemand hinlaufen und so 144 00:10:04,760 --> 00:10:09,339 „Build“ klicken. Und das ist auch nicht schlau. Ich habe hier mal versucht, ein 145 00:10:09,339 --> 00:10:16,129 Bild herauszusuchen. Die Idee beim Build-Server ist es, dass der am besten 146 00:10:16,129 --> 00:10:20,669 automatisiert baut, und zwar mindestens einmal täglich. So, das habe ich auch 147 00:10:20,669 --> 00:10:22,879 schon erlebt: der Build ist fehlgeschlagen, und dann hat der 148 00:10:22,879 --> 00:10:25,749 Entwickler eben auf dem Build-Server angefangen, irgendwelche Dateien zu 149 00:10:25,749 --> 00:10:31,470 editieren. Das ist jetzt gerade im Wachstum von Devops ein Problem, was wir 150 00:10:31,470 --> 00:10:35,249 häufiger sehen werden, glaube ich. Das macht natürlich den Vorteil vom Build- 151 00:10:35,249 --> 00:10:39,109 Server komplett kaputt, ja? Weil, dann habe ich wieder den Effekt, das ist ja der 152 00:10:39,109 --> 00:10:42,639 Rechner vom Developer, aber es ist halt nicht mehr der unter seinem Tisch, sondern in 153 00:10:42,639 --> 00:10:47,289 dem Rack da hinten, wo „Build-Server“ dransteht. So, ich hoffe, dass wir demnächst 154 00:10:47,289 --> 00:10:50,239 ein Debian haben werden, was diese Namenskonvention übernimmt. 155 00:10:50,239 --> 00:10:53,750 *Gelächter* Das sieht man auch häufig, ja, nicht nur 156 00:10:53,750 --> 00:10:56,529 auf Build-Servern, sondern das wird halt irgendwann aufgesetzt und danach bleibt 157 00:10:56,529 --> 00:11:00,170 das halt so. Und das hält das ganze Projekt zurück, weil dann irgendwelche 158 00:11:00,170 --> 00:11:04,259 Software-Versionen da drauf sind. So übliche Sachen sind irgendwie eine SSL-Library, 159 00:11:04,259 --> 00:11:09,040 die kein aktuelles TLS 1.2 kann. Und das werden wir mit 1.3 demnächst wieder haben, 160 00:11:09,040 --> 00:11:12,919 das Problem. Oder irgendwie ein uraltes C++, und dann können die Leute die neuen 161 00:11:12,919 --> 00:11:16,479 Features nicht benutzen. Also das ist alles ganz furchtbar. Will das mal hier 162 00:11:16,479 --> 00:11:20,639 mit so einem schönen Müllhaufen illustrieren. Der Grund, warum man einen 163 00:11:20,639 --> 00:11:25,190 Build-Server hat, ist, dass man täglich bauen kann, automatisiert, ohne dass da 164 00:11:25,190 --> 00:11:29,879 jemand hingehen muss, und ohne dass jemand hingehen kann, um irgendwas zu fixen. Da 165 00:11:29,879 --> 00:11:33,979 gibt es keine Interaktion außer: „Bau mal diese Version“, ja? Der Build soll 166 00:11:33,979 --> 00:11:37,599 deterministisch sein. Das ist leider unabhängig vom Build-Server, muss ich euch 167 00:11:37,599 --> 00:11:41,109 erzählen. Es gibt tatsächlich Build- Prozesse, da fällt jedesmal ein anderes 168 00:11:41,109 --> 00:11:44,600 Binary raus, auch wenn man keine neue Version ausgecheckt hat, weil irgendwie 169 00:11:44,600 --> 00:11:48,569 parallel gebaut wird und irgendwelche Dateien, die gebraucht werden, werden 170 00:11:48,569 --> 00:11:52,209 asynchron von anderen Teilen aus dem Parallel-Build erzeugt. Und wenn man Glück 171 00:11:52,209 --> 00:11:56,299 hat, kommt die richtige an. Und wenn man Pech hat, halt nicht. Also das muss man 172 00:11:56,299 --> 00:12:00,959 fixen. Das ist Arbeit. Und es wäre mir sehr lieb, dass so Open-Source-Entwickler 173 00:12:00,959 --> 00:12:06,719 auch alle dafür sorgen, dass ihre Projekte mit beliebiger Parallelität baubar sind. 174 00:12:06,719 --> 00:12:09,819 Der nächste Grund für Build-Server ist Agilität. 175 00:12:09,819 --> 00:12:12,179 *Applaus* Ja? Wenn ich irgendwas kaputtgemacht habe, 176 00:12:12,179 --> 00:12:15,579 dann soll keine Panik ausbrechen, sondern dann sage ich „Rollback“ und bau halt die 177 00:12:15,579 --> 00:12:19,349 Version von vorhin nochmal, die funktioniert hat. Wenn das nicht ein 178 00:12:19,349 --> 00:12:23,690 Knopfdruck ist, dann könnt ihr den Build- Server auch wegschmeißen. Und natürlich 179 00:12:23,690 --> 00:12:27,960 möchte man möglichst schnell mitkriegen, wenn jemand was eingecheckt hat, was den 180 00:12:27,960 --> 00:12:32,419 Build bricht. Aber nicht sanktionieren! Ich habe mal so eine Firma erlebt, die hat 181 00:12:32,419 --> 00:12:35,849 dann so ein Britney-Spears-T-Shirt gehabt, und das musste der Typ tragen, der den 182 00:12:35,849 --> 00:12:38,489 letzten, zum letzten Mal den Build gebrochen hat. 183 00:12:38,489 --> 00:12:43,720 *Lachen und Applaus* Macht das nicht. Das hat gut funktioniert, 184 00:12:43,720 --> 00:12:46,410 bis sie so einen Britney-Spears-Fan als Angestellten hatten. 185 00:12:46,410 --> 00:12:52,160 *Lachen* Ja. So, also das nächste Problem: ich habe 186 00:12:52,160 --> 00:12:55,079 jetzt zwar einen Build-Server, und der baut das zwar unabhängig vom 187 00:12:55,079 --> 00:12:58,460 Entwicklerrechner, aber das Binary funktioniert nur auf dem Rechner vom 188 00:12:58,460 --> 00:13:03,859 Entwickler. Ist ein subtil anderes Problem, aber verwandt. Und das löst man 189 00:13:03,859 --> 00:13:07,030 heute mit Docker, ist ja klar! *Applaus* 190 00:13:07,030 --> 00:13:10,809 Und Docker ist im Prinzip keine schlechte Idee. Man darf halt nicht Seal Team 6 191 00:13:10,809 --> 00:13:14,609 basteln lassen. Denn da kommen dann so Effekte wie: ich lutsche mir 192 00:13:14,609 --> 00:13:18,919 irgendwelche Images von irgendwo aus dem Internet rein. Klassiker sind so Ramses- 193 00:13:18,919 --> 00:13:24,919 der-Zweite-Debian und MySQL drei Punkt irgendwas von neunzehnhundert-äh. 194 00:13:24,919 --> 00:13:29,569 So, dafür ist Docker nicht da. Docker ist gerade dafür da, dass das agil änderbar 195 00:13:29,569 --> 00:13:33,139 ist. Und wenn ihr das nicht macht, dann ist es, als wenn ihr nicht lest. Könnt ihr 196 00:13:33,139 --> 00:13:37,059 euch das gleich sparen. Also ich habe hier mal Frankenstein als Illustration 197 00:13:37,059 --> 00:13:41,039 gebracht. Das bringt nichts. Dann habt ihr so ein Schrott-Projekt am Ende. Ich sehe 198 00:13:41,039 --> 00:13:44,409 das häufig in der Industrie, dass die Leute alle Nachteile mitnehmen, aber die 199 00:13:44,409 --> 00:13:49,279 Vorteile gezielt stehen lassen. *Lachen und Applaus* 200 00:13:49,279 --> 00:13:52,880 Häufig gerade bei so Build-Systemen und Docker ist, dass man die Komponenten in 201 00:13:52,880 --> 00:13:56,209 irgendwelchen statischen Versionen hart- codet, die halt aktuell waren, als es 202 00:13:56,209 --> 00:14:01,749 aufgesetzt wurde, und danach nicht mehr geupdatet werden, ja? Also ich habe in den 203 00:14:01,749 --> 00:14:04,819 letzten Jahren immer mehr Leute mit Build-Servern gesehen, die alles 204 00:14:04,819 --> 00:14:08,789 automatisiert bauen. Und alle Dateien im Image haben so denselben Time- 205 00:14:08,789 --> 00:14:12,629 Stamp grob. Also man sieht, dass es alles frisch gebaut wurde, aber es sind trotzdem 206 00:14:12,629 --> 00:14:18,399 Versionen von 2004. Das ist sehr häufig, achtet darauf bei euch, ja? Und wenn ein 207 00:14:18,399 --> 00:14:22,829 Zulieferer euch Kram gibt, der vom Build-Server kommt mit alten Versionen, 208 00:14:22,829 --> 00:14:27,029 dann weist ihn darauf hin. Negatives Feedback. Das ist sonst wie so ein 209 00:14:27,029 --> 00:14:34,850 Rollator: bremst nur. Container hat man für automatisiertes Deployment in 210 00:14:34,850 --> 00:14:39,459 deterministischem Zustand. Das ist eine Sache, die haben fast alle verstanden. 211 00:14:39,459 --> 00:14:43,050 Aber was nicht so verstanden wird, ist dieser, der Rollback ist eben auch 212 00:14:43,050 --> 00:14:47,239 trivial, wenn man das mit so einem Docker- System baut. Dann klicke ich halt „Mach mal 213 00:14:47,239 --> 00:14:50,729 die alte Version“ und dann fällt das Image der alten Version raus. Das ist ein 214 00:14:50,729 --> 00:14:54,169 Feature, das ist nicht ein Seiteneffekt, sondern das ist einer der Gründe, warum 215 00:14:54,169 --> 00:14:58,849 man das überhaupt hat. Nutzt das auch. Das ist nicht mehr… es tut nicht mehr weh, 216 00:14:58,849 --> 00:15:02,210 wenn man was kaputtmacht im Build, sondern dann kann ich zurückrollen. Nicht 217 00:15:02,210 --> 00:15:06,509 nur im Versionierungssystem, sondern ich kann auch einfach komplett, einen neuen 218 00:15:06,509 --> 00:15:10,679 Build, fällt dann halt raus. Und am besten macht man sowas über die Mittagspause, ja? 219 00:15:10,679 --> 00:15:14,860 Daher vorhin der Ratschlag, im Skript Abhängigkeiten testen. Und nicht nach zwei 220 00:15:14,860 --> 00:15:18,990 Stunden den Build failen lassen. Docker ist… und Container sind 221 00:15:18,990 --> 00:15:22,389 eigentlich eine gute Idee. Aber die meisten Leute nehmen nur die Nachteile 222 00:15:22,389 --> 00:15:29,689 mit. Komponenten kann man agil updaten. Das muss man auch tun. Also ist hier keine 223 00:15:29,689 --> 00:15:32,559 schwarze Magie, die ich hier erzähle. Aber es ist erstaunlich, wie viele Leute das 224 00:15:32,559 --> 00:15:37,100 nicht machen. Und der mir als Security-Typ natürlich am wichtigsten erscheinende 225 00:15:37,100 --> 00:15:41,399 Aspekt bei Containern ist, dass man damit Komponenten im Gesamtsystem isolieren kann 226 00:15:41,399 --> 00:15:45,970 voneinander. Dass nicht ein Typ, der diesen einen Prozess hackt, automatisch 227 00:15:45,970 --> 00:15:49,949 alle anderen im Zugriff hat. Sondern die laufen halt in ihren eigenen Containern. 228 00:15:49,949 --> 00:15:53,350 Aber in der Praxis sieht man, dass dann der Monster-Container gebaut wird mit den 229 00:15:53,350 --> 00:16:00,300 50 Komponenten drin. Das ist nicht gut. Also nehmt alle Vorteile mit. Richtig gut 230 00:16:00,300 --> 00:16:04,799 ist das natürlich erst in Kombination, ja? Der Git hat alle Versionen und dem Build- 231 00:16:04,799 --> 00:16:07,830 Server kann ich eine Version zurufen und dann fällt ein Image raus ohne 232 00:16:07,830 --> 00:16:13,099 Abhängigkeiten. So, wenn ihr das nicht habt, dann benutzt ihr das nicht richtig. 233 00:16:13,099 --> 00:16:18,709 Ganz einfach. Das nächste Problem ist: Der Code funktioniert nicht. Das kennen 234 00:16:18,709 --> 00:16:22,360 wahrscheinlich auch alle, ist ein Problem. Was machen wir jetzt? Und die Lösung ist: 235 00:16:22,360 --> 00:16:27,809 Unit-Tests! Und die Umsetzung ist häufig: ich habe hier gerade einen Bug, den fixe 236 00:16:27,809 --> 00:16:32,559 ich mal, und den Check, ob der Bug weg ist, den mache ich jetzt als Unit-Test. Ja 237 00:16:32,559 --> 00:16:35,919 und das ist nicht gut. Da kriegt man dann so eine Coverage von 2,3 Prozent, wenn es 238 00:16:35,919 --> 00:16:40,730 hoch kommt. Und ich weiß nicht, ob ihr alle das Video hier gesehen habt. Das war 239 00:16:40,730 --> 00:16:43,839 so ein Automat, der erkennen sollte, ob eine Hand drunter gehalten wurde. Und der 240 00:16:43,839 --> 00:16:48,199 wurde halt von Weißen gemacht. Und die haben halt nie eine andere Hautfarbe 241 00:16:48,199 --> 00:16:52,560 getestet. Und da kommt dann halt nix raus. So, das ist ein typischer Fall von „Unit- 242 00:16:52,560 --> 00:16:59,439 Test-Abdeckung zu gering“. Ich glaube auch, dass hier die Perspektive die 243 00:16:59,439 --> 00:17:02,709 falsche ist häufig. Die Leute glauben, sie machen Unit-Tests, damit sie wissen, dass 244 00:17:02,709 --> 00:17:08,299 der Code jetzt okay ist. Nein! Unit-Tests sind dafür da, dass sich was ändern kann 245 00:17:08,299 --> 00:17:12,690 und [man] sehen kann, ob es -noch- geht. Damit ich keine Angst mehr haben muss, 246 00:17:12,690 --> 00:17:17,160 alten Code anzufassen. Das ist das, was Unit-Tests euch abnehmen: die Angst, in 247 00:17:17,160 --> 00:17:21,830 altem Code was zu fixen. Weil ihr den nicht komplett versteht oder so. Und 248 00:17:21,830 --> 00:17:26,979 je mehr Abdeckung ihr mit den Unit-Tests habt, desto stärker ist diese Waffe. 249 00:17:26,979 --> 00:17:35,540 Nutzt das. *Applaus* 250 00:17:35,540 --> 00:17:38,810 Ich muss hier ein bisschen durchgaloppieren, weil ich zu viele Folien habe. Ich hoffe, 251 00:17:38,810 --> 00:17:42,249 das verzeiht ihr mir. So, das nächste Problem sind, dass die Leute nur positive 252 00:17:42,249 --> 00:17:47,230 Tests haben. Die gucken: funktioniert das hier? Und der Effekt ist normalerweise so gut 253 00:17:47,230 --> 00:17:51,229 wie keiner, denn die ganzen interessanten Bugs sind in der Fehlerbehandlung, dafür 254 00:17:51,229 --> 00:17:55,980 braucht ihr auch Unit-Tests. Und zwar müsst ihr eigentlich für alles, was 255 00:17:55,980 --> 00:18:00,640 fehlschlagen kann, einen Test haben, der das fehlschlagen lässt. Und dann gucken, 256 00:18:00,640 --> 00:18:05,620 ob das immer noch funktioniert, wie es soll. Das sind die Sachen, die am Ende 257 00:18:05,620 --> 00:18:09,930 über Bande woanders einen Fehler erzeugen, ja? Irgendwie eine Memory Corruption in 258 00:18:09,930 --> 00:18:13,699 einem Fehlerfall, oder irgendwie „RAM wird nicht freigegeben im Fehlerfall“. Und dann 259 00:18:13,699 --> 00:18:16,840 stellt sich raus: das kann man als Angreifer triggern. Und dann habe ich einen 260 00:18:16,840 --> 00:18:21,320 Remote-Memory-Leak und der Prozess crasht. Diese Art von Sachen sind völlig überflüssig 261 00:18:21,320 --> 00:18:26,539 und mit ordentlichen Unit-Tests abfangbar. Also macht das. Unit-Tests sind aber kein 262 00:18:26,539 --> 00:18:29,389 Allheilmittel, den Eindruck möchte ich nicht vermitteln. Selbst wenn ich 100% 263 00:18:29,389 --> 00:18:33,010 Unit-Test-Coverage habe, kann ich immer noch einen Fall übersehen haben. 264 00:18:33,010 --> 00:18:36,691 Dennoch: das ist ein Ziel, was ihr haben solltet. Es gibt Tools, um die Coverage zu 265 00:18:36,691 --> 00:18:42,840 prüfen. Nutzt diese Tools. Das ist wichtig. So, der nächste Fall, jetzt habe 266 00:18:42,840 --> 00:18:45,800 ich Unit-Tests ausgerollt, ist: die Entwickler haben Fälle vergessen zu 267 00:18:45,800 --> 00:18:51,370 testen, ja? Das kommt häufig vor. Und da gibt es einen neuen Hype: Test- 268 00:18:51,370 --> 00:18:55,340 Driven-Development. Du schreibst erst die Tests und dann den Code. Und da kann ich 269 00:18:55,340 --> 00:18:58,810 leider nichts zu sagen, weil ich das noch nie in der Produktion gesehen habe. 270 00:18:58,810 --> 00:19:02,100 Ich kenne nur Leute… 271 00:19:02,100 --> 00:19:07,220 *Lachen und Applaus* 272 00:19:07,220 --> 00:19:10,710 Ich kenne nur Leute, die sich ganz sicher sind, dass das total geil ist. Aber ich 273 00:19:10,710 --> 00:19:13,130 habe es noch nie… also wenn ihr da irgendwie wisst, dann schreibt mir mal 274 00:19:13,130 --> 00:19:16,990 eine Mail, das würde mich echt interessieren. Ja, das nächste Problem 275 00:19:16,990 --> 00:19:20,330 ist: wir haben hier Code, und der tut irgendwas, aber wir haben keine Ahnung, 276 00:19:20,330 --> 00:19:24,380 wie das funktioniert. Und die Lösung ist natürlich: Dokumentation! Ist auch eine 277 00:19:24,380 --> 00:19:28,120 gute Idee, das will ich keinem ausreden. Aber es kommt häufig vor, Seal Team 6 278 00:19:28,120 --> 00:19:32,860 setzt ein Wiki auf, und da gibt es ganz häufig so Effekte – da werde ich hier 279 00:19:32,860 --> 00:19:38,120 Congress-Teilnehmern nichts Neues erzählen – das Zertifikat ist gerade abgelaufen 280 00:19:38,120 --> 00:19:41,770 oder das Wiki wirft Exceptions oder ist nicht erreichbar oder so. Das ist ganz 281 00:19:41,770 --> 00:19:47,350 häufig. Und dann fallen so Sätze wie: „Ja, das hatte ich, glaube ich, ins Wiki getan“. 282 00:19:47,350 --> 00:19:52,369 Und so: „Ja, das musst du halt bookmarken, weil Navigation haben wir noch nicht“. Und 283 00:19:52,369 --> 00:19:58,739 ganz häufig gibt es auch: „Jaja, das hier oben, das stimmt nicht mehr“. 284 00:19:58,739 --> 00:20:04,240 Also Wiki ist keine Lösung. Je kleiner man die Schwelle setzt dafür, da was zu 285 00:20:04,240 --> 00:20:08,529 editieren, desto mehr fällt es unter den… vom Tisch. Weil die Leute 286 00:20:08,529 --> 00:20:12,319 einfach das nicht als als wichtigen Schritt sehen, sondern als so kleines 287 00:20:12,319 --> 00:20:18,409 Ding. Das muss ein richtiger Schritt im System sein, im Produktivbetrieb, dass 288 00:20:18,409 --> 00:20:23,340 man sagt: „Jede Änderung wird dokumentiert, Punkt.“ So, die nächste Idee, die man in 289 00:20:23,340 --> 00:20:26,520 großen Firmen häufig hört, dass man sagt: „Wir müssen hier mehr Kommunikation haben, 290 00:20:26,520 --> 00:20:32,620 die Leute reden zu wenig miteinander“. Und dann hat man so Großraumbüros. 291 00:20:32,620 --> 00:20:40,880 *Lachen und Applaus* 292 00:20:40,880 --> 00:20:43,670 Habe ich auch noch nie funktionieren sehen. 293 00:20:43,670 --> 00:20:46,440 Das klappt nicht, ja? Menschen müssen sich mal am Stück konzentrieren 294 00:20:46,440 --> 00:20:50,029 können. Und je mehr Unterbrechung man hat, desto schlechter ist das. Und heute geht 295 00:20:50,029 --> 00:20:52,300 der Trend sogar dahin… 296 00:20:52,300 --> 00:20:57,810 *Applaus* 297 00:20:57,810 --> 00:21:00,879 Heute geht der Trend sogar dahin, dass die Leute sich Slack installieren. Die 298 00:21:00,879 --> 00:21:05,070 plakatieren gerade in Berlin. Also, die sich absichtlich gegenseitig unterbrechen. 299 00:21:05,070 --> 00:21:08,570 Ist mir völlig ein Rätsel, warum Leute sowas tun würden. Denn nach jeder 300 00:21:08,570 --> 00:21:12,040 Unterbrechung braucht man so eine Viertelstunde, bis man wieder drin ist. 301 00:21:12,040 --> 00:21:16,899 Und diese Chatsysteme und auch Mail- Unterbrechungen sind darauf ausgelegt, 302 00:21:16,899 --> 00:21:22,130 dass man nie diese 15 Minuten schafft. Ja, ich weiß, die Zeit ist knapp, ist gut! 303 00:21:22,130 --> 00:21:23,690 *lacht* *Lachen* 304 00:21:23,690 --> 00:21:29,899 Meetings, ja. Meetings. Da muss ich, glaube ich, nicht viel zu sagen. 305 00:21:29,899 --> 00:21:32,460 Aber der Effekt ist immer derselbe: ich kann mich nicht konzentrieren. Und das 306 00:21:32,460 --> 00:21:35,920 ist ein ernstes Problem. Da muss man aktiv gegenhalten, 307 00:21:35,920 --> 00:21:39,230 ja? Das ist nicht so einfach. Ich habe jetzt überlegt: soll ich vorschlagen, die 308 00:21:39,230 --> 00:21:42,389 Meetings kurz zu machen? Aber das ist so, habe ich auch nie funktionieren sehen, den 309 00:21:42,389 --> 00:21:46,779 Ratschlag. Alle Leute glauben immer, sie machen ihre Meetings kurz. Funktioniert 310 00:21:46,779 --> 00:21:51,720 nicht. Daher sage ich: lieber selten und One-on-One. Denn wenn man jetzt irgendein 311 00:21:51,720 --> 00:21:55,580 Problem klären will, und da sitzen alle Leute aus dem Team, dann gibt es eine 312 00:21:55,580 --> 00:21:58,230 höhere Schwelle für den Einzelnen, zu sagen: „Ja, da habe ich einen Fehler 313 00:21:58,230 --> 00:22:01,300 gemacht.“ Deswegen lieber einzeln. 314 00:22:01,300 --> 00:22:04,790 *Applaus* 315 00:22:04,790 --> 00:22:08,769 Niemand, niemand hat Bock darauf, sich vor seinen Kollegen zu entblößen. Und das muss 316 00:22:08,769 --> 00:22:13,370 man also nicht künstlich herbeiführen. So, jetzt kommen wir zur Security-Abteilung. 317 00:22:13,370 --> 00:22:16,230 Wir haben Code und er tut irgendwas, aber wir trauen dem nicht. Was machen wir 318 00:22:16,230 --> 00:22:22,211 jetzt? Nächste Idee: naja okay, wir machen erstmal die Compiler-Warnungen weg, ja? 319 00:22:22,211 --> 00:22:26,489 Gute Idee. Der Effekt ist – und ich war schockiert, dass es da einen Begriff für 320 00:22:26,489 --> 00:22:31,290 gibt: Onion-Code. So, Onion-Code bedeutet, dass ich so einen Chunk Legacy-Code habe, 321 00:22:31,290 --> 00:22:34,769 der total viele Warnungen drin hat, und den seit fünf Jahren keiner mehr angefasst 322 00:22:34,769 --> 00:22:39,160 hat. Und da findet jetzt jemand einen Bug drin. Und der würde den gerne fixen. Aber 323 00:22:39,160 --> 00:22:43,190 dann compilet der Rest immer noch mit den ganzen Warnungen. Und die müsste ich dann 324 00:22:43,190 --> 00:22:47,220 fixen, damit ich den Fix einchecken kann für den Bug. Und ich verstehe diesen Code 325 00:22:47,220 --> 00:22:50,669 aber nicht. Ich verstehe nur den kleinen Teil, wo ich den Bug gefunden habe. Und 326 00:22:50,669 --> 00:22:55,750 dann mache ich einen Layer drum rum, und der guckt diesen einen Fall, fängt ihn ab. 327 00:22:55,750 --> 00:22:59,060 Und wenn das mehrere Leute machen, hat man so eine Zwiebel. Und deswegen heißt das 328 00:22:59,060 --> 00:23:03,749 Onion-Code. Das ist ganz furchtbar, ja? 329 00:23:03,749 --> 00:23:09,590 Wenn ihr das irgendwo seht, dann ‚burn it with fire‘! 330 00:23:09,590 --> 00:23:12,819 So, nächster Vorschlag: wir haben nur noch Releases ohne offene Bugs. Das klingt auch 331 00:23:12,819 --> 00:23:17,280 total super. Und ich war auch mal bei einem Kunden, der das probiert hat, 332 00:23:17,280 --> 00:23:22,010 und da kam dann so eine Mail: „Mach mal deine Bugs alle zu.“ Und 333 00:23:22,010 --> 00:23:24,620 dann meine ich so: „Ich bin aber hier, um Bugs aufzumachen, nicht um sie 334 00:23:24,620 --> 00:23:28,349 zuzumachen.“ Und dann meinte er: „Ja, die machen wir danach wieder auf, keine 335 00:23:28,349 --> 00:23:36,689 Sorge.“ *Lachen und Applaus* 336 00:23:36,689 --> 00:23:40,590 Muss ich, glaube ich, nicht erläutern, ob die wieder aufgemacht wurden oder nicht. 337 00:23:40,590 --> 00:23:43,719 Ja, externer Audit, und das tut mir in der Seele weh, denn das biete ich geschäftlich 338 00:23:43,719 --> 00:23:47,549 an, ja, das ist leider auch teilweise ein Antipattern. Denn was hier passiert, ist, 339 00:23:47,549 --> 00:23:51,689 dass die Leute so einen Blackbox-Pentest beauftragen. Und ein Blackbox-Pentest 340 00:23:51,689 --> 00:23:54,700 heißt, der Tester hat keinen vollen Zugriff auf das System, der weiß nicht, 341 00:23:54,700 --> 00:23:57,799 wie das funktioniert, sondern soll das in dem Test selber rausfinden. Und dann 342 00:23:57,799 --> 00:24:02,259 passiert sowas hier. Und was mich an der Stelle am meisten beeindruckt hat, ist, 343 00:24:02,259 --> 00:24:07,480 dass es dieses Bild schon gab. Das habe ich jetzt nicht gemacht. So, das ist 344 00:24:07,480 --> 00:24:12,089 leider üblich. Man testet nicht den Code, sondern man testet den Pentester. Und ich 345 00:24:12,089 --> 00:24:15,349 als Pentester habe jetzt natürlich… könnte jetzt sagen: „Ja, ist mir doch egal, wen 346 00:24:15,349 --> 00:24:19,579 die da testen, solange ich bezahlt werde.“ Aber ich habe da so einen Moralkodex. Ich 347 00:24:19,579 --> 00:24:23,072 hätte gern dem Kunden geholfen und nicht nur das Geld genommen. Das ist für alle 348 00:24:23,072 --> 00:24:27,462 Seiten Scheiße. Macht das nicht. Ja, Pentests. Ich sage, das ist ein 349 00:24:27,462 --> 00:24:31,719 Compliance-Problem, dass die Leute alle aus Compliance-Gründen Pentests machen. 350 00:24:31,719 --> 00:24:35,300 Und das ist eigentlich an sich schon ein furchtbares Zeichen, dass wir die Security 351 00:24:35,300 --> 00:24:38,930 nicht hinkriegen, sondern Compliance brauchen, um uns dazu zu bringen, dass wir 352 00:24:38,930 --> 00:24:44,989 doch Security machen. Wir sollten uns alle schämen! Fuzzing ist auch so ein Ding. Das 353 00:24:44,989 --> 00:24:49,500 wird gerne gemacht. Fuzzing heißt, dass ich zufällige Eingaben generiere und gegen 354 00:24:49,500 --> 00:24:52,959 meinen Endpunkt werfe und gucke, ob der platzt oder nicht. Und das ist 355 00:24:52,959 --> 00:24:56,929 erschütternd erfolgreich, ja? Das funktioniert. Und ich habe mal erlebt, 356 00:24:56,929 --> 00:24:59,731 dass sie gesagt haben: „Nee, den Code hier, den musst du nicht testen, den haben 357 00:24:59,731 --> 00:25:04,100 wir schon zu Tode gefuzzt. Seit Monaten läuft unsere Fuzzing-Farm.“ Und da stellt 358 00:25:04,100 --> 00:25:06,999 sich dann heraus: die haben zwar Milliarden von Test-Cases geprüft. Aber 359 00:25:06,999 --> 00:25:11,809 das war immer derselbe. *Lachen* 360 00:25:11,809 --> 00:25:16,000 Total super. Und häufig ist Fuzzing so ein Feigenblatt, womit dann andere Maßnahmen 361 00:25:16,000 --> 00:25:18,470 nicht gemacht werden, weil wir haben doch schon gefuzzt, und das ist auch in 362 00:25:18,470 --> 00:25:21,989 Ordnung, ja? Also ich habe nichts gegen Fuzzing an sich, denn es funktioniert 363 00:25:21,989 --> 00:25:31,610 leider. Aber es darf kein Hindernis dafür sein, andere wichtige Maßnahmen zu machen. 364 00:25:31,610 --> 00:25:35,230 Das ist ein generelles Problem, was ich häufiger sehe, dass, wenn das Management 365 00:25:35,230 --> 00:25:39,579 die Wahl hat zwischen einer Maßnahme, die wahrscheinlich funktioniert, aber keine 366 00:25:39,579 --> 00:25:43,379 Metriken abwirft, und einer Maßnahme, die wahrscheinlich nicht funktioniert, aber 367 00:25:43,379 --> 00:25:48,199 Metriken abwirft, dass immer die mit den Metriken gemacht wird. Management liebt 368 00:25:48,199 --> 00:25:51,900 qualifizierbare Geschichten, wo irgend… quantifizierbare Geschichten, wo 369 00:25:51,900 --> 00:25:56,279 irgendeine Zahl rausfällt. Und das geht häufig nach hinten los, ja? Ich habe also 370 00:25:56,279 --> 00:26:01,630 mal so ein… das war ein wirklich schockierendes Erlebnis für mich. Ich bin, 371 00:26:01,630 --> 00:26:05,820 ich sage mal preiswert, aber nicht billig, ja, also meine Tagessätze. – Ich weiß, ich 372 00:26:05,820 --> 00:26:11,160 weiß! – So und dann gehe ich dahin, zu dem Kunden, und der Kunde sagt: „Geh mal nach 373 00:26:11,160 --> 00:26:15,360 Hause.“ Also ich wurde trotzdem bezahlt, ja? Haben gesagt: „Geh mal nach Hause.“ 374 00:26:15,360 --> 00:26:19,730 Und ich so: „Wie jetzt?“ „Ja, ist warm heute.“ Meinte ich so: „Was?“ „Ja die 375 00:26:19,730 --> 00:26:23,110 Klimaanlage reicht für das Fuzzing-Lab oder die Consultants.“ 376 00:26:23,110 --> 00:26:31,720 *Lachen und Applaus* Ja. Gut. Das nächste Problem, das ist so 377 00:26:31,720 --> 00:26:35,580 ein bisschen schwierig. Aber es ist mir sehr wichtig, weil das so gerade im Kommen 378 00:26:35,580 --> 00:26:40,650 ist. Die Coder sind überfordert. Und dann sagt man: wir brauchen irgendeinen soliden 379 00:26:40,650 --> 00:26:43,820 Ansatz. Thread-Modeling! Das ist gerade im Kommen. Und das ist eine gute 380 00:26:43,820 --> 00:26:47,520 Geschichte, aber es wird häufig missverstanden. Thread-Modeling, der 381 00:26:47,520 --> 00:26:50,890 übliche Ansatz ist, dass man sagt: jedes Team macht ein Thread-Model für den Code. 382 00:26:50,890 --> 00:26:56,419 Das ist gut. Ja? Aber häufig macht dann der Feature-Owner oder Projektmanager 383 00:26:56,419 --> 00:27:00,350 mit dem Dokumentationsteam zusammen, füllt irgendwelche Formulare aus, und die 384 00:27:00,350 --> 00:27:05,049 Developer sind überhaupt nicht betroffen. Und das ist ein krasser Fehler. Denn beim 385 00:27:05,049 --> 00:27:09,079 Thread-Modeling geht es nicht um das Papier am Ende. Das ist kein Zertifikat. 386 00:27:09,079 --> 00:27:13,549 Sondern es geht um den Weg zum Papier. Es geht darum, dass die Entwickler mal aus 387 00:27:13,549 --> 00:27:17,229 der Sicht des Angreifers versuchen, auf ihren Code zu gucken, dass sie verstehen, 388 00:27:17,229 --> 00:27:21,239 was da Angriffsoberfläche ist, dass sie sehen, wo die Sachen sind, auf die man 389 00:27:21,239 --> 00:27:25,099 aufpassen muss, welche Angriffe denkbar sind. Wenn jemand anderes das Thread-Model 390 00:27:25,099 --> 00:27:29,720 macht, das hätte man sich auch sparen können, ja? Also: Thread-Model ist gut, 391 00:27:29,720 --> 00:27:34,230 aber das müssen die Entwickler machen. Wir sind fast durch. Ich habe noch ein paar 392 00:27:34,230 --> 00:27:37,060 allgemeine Ratschläge, weil ich mir dachte: ich kann euch hier nicht so 393 00:27:37,060 --> 00:27:41,819 deprimiert nach Hause gehen lassen. Aus Sicht des Management ist aus meiner Seite 394 00:27:41,819 --> 00:27:44,800 ganz wichtig, dass man eine Fehlerkultur etabliert. Das heißt: niemand wird 395 00:27:44,800 --> 00:27:48,389 bestraft für Bugs. Denn sonst verstecken die Leute Bugs, und das ist noch 396 00:27:48,389 --> 00:27:51,610 schlechter, ja? Man muss Leute belohnen, … 397 00:27:51,610 --> 00:27:58,231 *Applaus* Man muss Leute belohnen, wenn sie 398 00:27:58,231 --> 00:28:02,239 einen Bug finden und fixen. Aber nicht mit Geld belohnen, sondern mit Ruhm und 399 00:28:02,239 --> 00:28:06,860 Ehre. Ich schlage immer vor, einmal die Woche, irgendwie Freitag ab 4 oder so, 400 00:28:06,860 --> 00:28:12,759 macht man so ein All-Hands-Meeting, wo – wenn die Leute wirklich was Anderes 401 00:28:12,759 --> 00:28:17,069 vorhaben, müssen sie nicht hingehen, also kein Zwang – aber wo dann die alten 402 00:28:17,069 --> 00:28:22,159 Hasen ihre schönsten Bugs erklären, ja? Damit es als etwas Positives gesehen wird, 403 00:28:22,159 --> 00:28:25,830 einen Bug zu finden, und damit die Jungen was dabei lernen. Das ist eine gute Sache, 404 00:28:25,830 --> 00:28:29,089 das kann ich empfehlen. Das funktioniert auch gut, und das bringt auch das Team 405 00:28:29,089 --> 00:28:35,009 zusammen. Und es nimmt so diesen Rockstar- Status weg, der auch nur schadet. So, die 406 00:28:35,009 --> 00:28:38,870 nächste Sache ist, dass man dafür sorgt, dass der Bug auch von dem gefixed wird, 407 00:28:38,870 --> 00:28:42,650 der den Code geschrieben hat. Es gibt große Firmen, die teilweise ein zweites 408 00:28:42,650 --> 00:28:46,729 Team dafür haben, Sicherheits-Bugs zu fixen. Und dann kriegt der Typ, der das 409 00:28:46,729 --> 00:28:49,320 programmiert hat, überhaupt nicht mit, dass er die ganze Zeit schlechten Code 410 00:28:49,320 --> 00:28:52,880 programmiert. Der zieht dann am besten noch so von Team zu Team, hinterlässt 411 00:28:52,880 --> 00:28:57,409 überall so Tretminen. Das ist wichtig, dass es Feedback gibt. Und zwar nicht als 412 00:28:57,409 --> 00:29:00,650 Strafe, sondern damit die Leute merken, wenn sie Fehler machen, ja? Menschen 413 00:29:00,650 --> 00:29:04,010 lernen aus ihren Fehlern. Dafür muss man verstehen, wenn man einen Fehler gemacht 414 00:29:04,010 --> 00:29:08,199 hat. Und das ist die, wo… komme ich zurück zu dieser Meeting-Kultur. Wenn man 415 00:29:08,199 --> 00:29:11,680 ein Meeting hat und sagt: „Du hast hier aber Scheiße gemacht“, dann macht man den 416 00:29:11,680 --> 00:29:15,640 vor dem ganzen Team nackig. Das hilft überhaupt nicht, ja? Man… es ist auch 417 00:29:15,640 --> 00:29:19,369 eine Kulturkreis-Frage. Manche Kulturkreise können damit besser umgehen 418 00:29:19,369 --> 00:29:24,980 als andere. Aber es gibt eben viele Leute, die haben ein starkes Problem damit, dass 419 00:29:24,980 --> 00:29:28,160 ihnen gesagt wird: „Du hast einen Fehler gemacht“, ja? Weil das, in Japan zum 420 00:29:28,160 --> 00:29:32,190 Beispiel ist es sehr wichtig, dass man der Firma hilft und nicht gesehen wird, wie 421 00:29:32,190 --> 00:29:36,281 man irgendwie an irgendwas schuld ist. Also das ist schwierig, so etwas 422 00:29:36,281 --> 00:29:40,209 aufzubauen. Aber das ist sehr wichtig. Fehler sind nicht schlecht, sondern aus 423 00:29:40,209 --> 00:29:46,040 den Fehlern kann man lernen, ja? Fehler sind gut. Dann finde ich, dass die Firma 424 00:29:46,040 --> 00:29:50,520 Werte kommunizieren sollte. Werte wie: uns ist der Code wichtiger, die Güte des 425 00:29:50,520 --> 00:29:54,789 Codes ist wichtiger als die Quantität, ja? Es kommt nicht darauf an, hier mehr Kram 426 00:29:54,789 --> 00:29:59,619 dran zu tun, sondern es kommt darauf an, dass wir, wenn wir was geschrieben haben, 427 00:29:59,619 --> 00:30:02,820 da auch noch einmal darauf zurückkommen später, ja? Wenn wir was dazugelernt 428 00:30:02,820 --> 00:30:07,929 haben, dass wir das auf den alten Code anwenden. Und damit das stressfrei machbar 429 00:30:07,929 --> 00:30:12,600 ist, braucht man ordentliche Unit-Tests. So haben wir dann so einen Kreisschluss. 430 00:30:12,600 --> 00:30:15,910 Die Anekdote, die ich hier erzählen wollte, war, dass ich mit einem Freund 431 00:30:15,910 --> 00:30:20,690 einen Job hatte. Und da war… Teil von dem Problem war ein User-Interface. Und da 432 00:30:20,690 --> 00:30:24,110 hatten wir beide überhaupt keine Ahnung von. Und der Freund meinte dann ganz 433 00:30:24,110 --> 00:30:27,980 locker: „Ja lass uns das in Qt machen.“ Und ich meinte so: „Wir haben beide keine 434 00:30:27,980 --> 00:30:30,990 Ahnung von Qt. Was machst du hier?“ Und da meint er: „Ja, das hätte ich gerne im 435 00:30:30,990 --> 00:30:34,319 Resümee stehen, ja? Das muss… in meinem Lebenslauf sieht das gut aus.“ Das ist 436 00:30:34,319 --> 00:30:37,349 schon ein paar Jahre her. Aber was ich sagen will: wenn die Firma den Leuten 437 00:30:37,349 --> 00:30:41,210 nicht die Zeit gibt, Sachen zu lernen, dann lernen sie das in Projekten der 438 00:30:41,210 --> 00:30:45,390 Firma, und die werden dann Scheiße. 439 00:30:45,390 --> 00:30:55,130 *Applaus* 440 00:30:55,130 --> 00:30:58,450 Was man auch häufiger sieht, ist, dass das Management glaubt, sie müsste die 441 00:30:58,450 --> 00:31:02,600 Architektur der Software vorgeben, oder welche Datenbank verwendet wird oder so. 442 00:31:02,600 --> 00:31:05,480 Und das ist eigentlich auch immer eine schlechte Idee. Denn entweder die 443 00:31:05,480 --> 00:31:08,659 Architektur ist offensichtlich, dann hilft es nichts. Oder sie ist nicht 444 00:31:08,659 --> 00:31:11,060 offensichtlich, dann sind die Ratschläge wahrscheinlich falsch, weil wir das 445 00:31:11,060 --> 00:31:14,730 Problem noch nicht wirklich verstanden haben. Also das ist auch eine Sache, da 446 00:31:14,730 --> 00:31:18,490 sollte sich das Management zurücknehmen an der Stelle. 447 00:31:18,490 --> 00:31:23,550 *Applaus* Und hier noch so ein bisschen Selbsthilfe 448 00:31:23,550 --> 00:31:28,409 für Entwickler. Ist die letzte Folie, ganz entspannt bleiben. Der Druck kommt immer 449 00:31:28,409 --> 00:31:32,690 von euch selbst. Das Management kann viel erzählen, ja? Deadline hier, Deadline da. 450 00:31:32,690 --> 00:31:37,330 Lasst euch da nicht dazu bringen, Überstunden zu fahren. Immer schön um 9 451 00:31:37,330 --> 00:31:44,280 kommen, um 5 nach Hause gehen. Also… *Applaus* 452 00:31:44,280 --> 00:31:49,800 Wenn unrealistische Anforderungen reinkommen, dann müsst ihr da ganz ehrlich 453 00:31:49,800 --> 00:31:52,910 sein und sagen: „Das wird wahrscheinlich nicht klappen. Ich nehme jetzt euer Geld 454 00:31:52,910 --> 00:31:56,729 und arbeite daran. Aber ich sage euch jetzt: das wird nix, ja?“ Immer schön 455 00:31:56,729 --> 00:32:00,460 Paper-Trail hinterlassen, dass das nichts wird und man es rechtzeitig gesagt hat. 456 00:32:00,460 --> 00:32:03,230 Man kann dann dran arbeiten, weil viele von euch werden wahrscheinlich die Kohle 457 00:32:03,230 --> 00:32:07,110 brauchen, aber ehrlich sein, nicht so tun, als wenn wir das mit ein paar irgendwie 458 00:32:07,110 --> 00:32:10,920 die-Nacht-durchgemacht am Ende noch reißen können. Das ist besonders in der 459 00:32:10,920 --> 00:32:15,600 Spielebranche ein riesiges Problem, dass die Leute total Burnout kriegen. Man muss 460 00:32:15,600 --> 00:32:19,460 das verstehen mit dem Management wie ein gegenseitiges Training, ja? Wenn ich dem 461 00:32:19,460 --> 00:32:22,969 Management so etwas durchgehen lasse, dann zeige ich ihnen: das ist die neue 462 00:32:22,969 --> 00:32:25,609 Baseline, ja? Das erwarten die ab dann. 463 00:32:25,609 --> 00:32:27,570 Herald: Soll ich mir einen Stuhl holen, damit ich mich daneben setze? 464 00:32:27,570 --> 00:32:28,939 Fefe: Kannst du machen, das ist die letzte Folie. 465 00:32:28,939 --> 00:32:31,219 Herald: Okay. Fefe: Ganz ruhig! 466 00:32:31,219 --> 00:32:33,769 So, und der letzte Satz, den ich habe: Zeit ist… muss man sich 467 00:32:33,769 --> 00:32:36,240 selber nehmen, ja? Ich habe zwar gerade gesagt… 468 00:32:36,240 --> 00:32:42,059 *Lachen und Applaus* 469 00:32:42,059 --> 00:32:50,299 Herald: Raus mit dir! *weiter Applaus* 470 00:32:50,299 --> 00:32:52,910 Ich habe zwar gerade dem Management empfohlen, euch Zeit zu geben, 471 00:32:52,910 --> 00:32:56,020 aber wenn ihr darauf wartet, das wird nichts. 472 00:32:56,020 --> 00:32:59,540 *Lachen* So, ich fürchte, die Fragezeit ist schon 473 00:32:59,540 --> 00:33:02,830 vorbei, oder? Herald: Jo. 474 00:33:02,830 --> 00:33:13,519 *Lachen und Applaus* 475 00:33:13,519 --> 00:33:17,269 Das Beeindruckende ist ja wirklich: die sind alle da geblieben, und da ist 476 00:33:17,269 --> 00:33:22,380 nicht einer vom Stuhl gefallen. Fefe: Ja! *lacht* 477 00:33:22,380 --> 00:33:27,749 Herald: Vielen, vielen Dank! Ausgänge sind beide offen. Das war’s von Fefe. 478 00:33:27,749 --> 00:33:30,339 Hier noch mal ein Applaus für ihn bitte! 479 00:33:30,339 --> 00:33:38,093 *Applaus* 480 00:33:38,093 --> 00:33:54,417 *Abspannmusik* 481 00:33:54,417 --> 00:33:59,301 *Untertitel erstellt von c3subtitles.de im Jahr 2018*