*34c3 preroll music*
Herald: Der Fefe hatte mich gebeten, mich kurz zu halten, weil, er hat Angst,
dass der Talk nicht in die 30 Minuten passt. Von daher gebe ich jetzt mal Gas und
sage: „Antipatterns und Missverständnisse in der Software-Entwicklung“!
Und wie sagte jemand gestern? „Ach Fefe! Das ist doch der mit der Kolumne
beim ehemaligen Nachrichtenmagazin!“ Here we go!
*Applaus*
Fefe: Hallo hallo. Hallo hallo. Ja, ja vielen Dank, dass ihr so zahlreich
erschienen seid. Ein bisschen zahlreicher, als ich gedacht habe. Nächstes Mal mache
ich doch lieber parallel zu Minkorrekt wieder. Es geht um Antipatterns.
Antipatterns sind Sachen, die man macht, die man häufig macht, die populäre
Maßnahmen sind, um ein Problem zu lösen, die dann aber entweder gar nicht
funktionieren oder nach hinten losgehen. Und ich habe mir gedacht, beim Congress
gibt es immer so schöne Streitereien um das Motto. Da mache ich auch mal ein Motto.
Und das hier ist so ein Motto, was ich sehr profunde finde, und wo ihr
hoffentlich im Laufe des Vortrags sehen werdet, warum das das Motto ist. Ja, „wer
lesen kann, aber es nicht tut, hat keinen Vorteil dem gegenüber, der das nicht kann“.
Die Struktur des Vortrags… *Applaus*
Die Struktur des Vortrags will ich an einem Beispiel kurz umreißen.
Es geht immer damit los, dass wir ein Problem haben.
Dann geht immer Seal Team 6 los und hackt irgendwas.
Also denkt euch hier ein Team von Spezialexperten. Ja ich will jetzt nicht
die Seals beleidigen, bestimmt auch alles nette Leute. Und dann kommt eine Umsetzung,
da geht es meistens in die Hose. Und dann haben wir einen Effekt, und
hoffentlich, hoffentlich eine Erkenntnis gewonnen. Ich habe mir gedacht, wir
versuchen mal so eine interaktive Komponente. Und zwar wenn man sich so
Übertragungen aus dem britischen Parlament ansieht, dann gibt es immer so ein
Gemurmel, wenn die Leute zustimmen. Und ich dachte mir, wenn ich sage, „Hebt mal
den Arm, wenn euch das mal passiert ist“, dann haben die Leute vielleicht Angst, auf
dem Stream zu landen und sich zu outen. Deswegen dachte ich, wir murmeln mal. Also
wenn einer von euch sich bei einem Muster wiedererkennt, könnt ihr mal versuchen.
Wir gucken mal, ob das klappt. Ja, vielleicht hört man das dann. Okay.
Also, erstes Problem. Dieses Bild, ich möchte das gleich dazusagen,
*Lachen* ist mir gespendet worden.
Ich liefere hier keine Kunden ans Messer, und es geht nur um Anekdoten.
Also wer sich glaubt, wiederzuerkennen, liegt wahrscheinlich falsch.
So, das ist ein typisches Problem in der Software-Entwicklung:
die Versionierung von und die Backups von alten Versionen aufzuheben.
Das ist hier, ich hoffe, ihr habt das gesehen oben in der Ecke, das ist ein USB-Stick.
Und die typische Idee ist: Wir machen jetzt mal ein Versionierungssystem!
Und das ist eine gute Idee. Die Umsetzung ist dann gewöhnlich:
der, der gerade ein akutes Problem hat, bastelt schnell was,
und dann kriegt man so ein Git. Und Git ist eigentlich gut, aber man hat halt
nicht nur Git, sondern man hat dann noch so ein paar andere Versionierungssysteme,
und da gehen dann die Probleme los. Ja also, ich habe mal einen, ich habe mal so
einen Kunden gehabt, die meinten: „Ist im Git“, und dann meinte der Typ daneben:
„Ja, musst noch sagen, in welchem“. Also das kommt vor.
*Lachen* Ein anderer Effekt, den man häufig
sieht, ist, dass jeder überall einchecken darf. Und das führt dann zu so Sachen wie:
man meldet als Bug so was wie: „In dem Image sind aber noch set-UID-Binaries“
oder sowas. Und dann machen die die alle weg, und dann installiert man die nächste
Version, und dann sind wieder welche, und dann sagt der Typ: „Ja, ich habe die zwar
alle weg gemacht, aber hat halt ein Developer wieder rein gemacht“.
Also Versionierung reicht noch nicht. Da muss man noch mehr machen.
Überhaupt die Idee, dass Leute Binaries einchecken, ist eine ganz schlechte.
Das findet man immer wieder. Ich rede jetzt hier nicht von png
oder irgendwie ein mpeg von einer Webseite oder sowas, sondern so eine Library oder
ein Executable. Das sollte man eigentlich nicht tun.
Es gibt ganz wenige Ausnahmen. Wenn ihr eine von den Ausnahmen habt,
wisst ihr es, und ansonsten macht es nicht!
Das hier ist jetzt natürlich überspitzt, aber so ähnlich habe ich das schon
mal gesehen, dass Leute verschiedene Versionen einchecken, aber nicht
verstanden haben, was eigentlich die Aufgabe von so einem Versionierungssystem ist.
Das ist auch nicht gut, macht das nicht!
Ich habe dann immer so einen Ratschlag am Ende von den jeweiligen Antipatterns.
Und mein Ratschlag für Versionierungssysteme ist: Git ist schon in Ordnung.
Ich bin mir der Ironie bewusst, dass meine eigene Software im Moment als CVS
im Internet ist. Das hat historische Gründe!
*Lachen und Applaus*
Patches hält man am besten klein, damit man sie einzeln anfassen kann,
wenn sie nicht sauber applyen. Das ist ein Riesenproblem, wenn jemand
so einen Megabyte-Patch abliefert. Deswegen macht das nicht.
Wenn ihr größere Sachen vorbereiten müsst, dann macht das nicht als einen großen
Patch, sondern nehmt einen eigenen Branch dafür. So ein Versionierungssystem will
euch helfen. Also beschäftigt euch mit den Features, die sie euch bieten.
Wenn man Annahmen hat, über, welche APIs verfügbar sind, oder welche Versionen von
Komponenten drin sein sollen, sollte man das im Build in einem Skript checken.
Und nicht erst anfangen zu bauen, und nach zwei Stunden abbrechen, weil irgendwas
nicht geklappt hat. Sowas möglichst vorher testen, damit es schnell failt,
damit man schnell reagieren kann.
Es gibt häufig so die Idee in Firmen, dass man verschiedene Abteilungen hat und jede
hat ihr eigenes Versionierungssystem oder ihr eigenes Repository. Und das kann
funktionieren, aber es ist sehr selten, ja? Häufig, der… der…
die Sache, die stimmen muss, damit es klappt, ist, dass die APIs stabil sind.
Und erfahrungsgemäß glauben alle, dass ihre APIs stabil bleiben werden, und
sie sind es dann aber nie. Also wenn ihr das vermeiden könnt, macht das nicht.
So, das nächste Problem ist: die Bugs fallen immer unter den Tisch, werden
vergessen, gefixt zu werden. Und die offensichtliche Lösung ist:
wir machen so einen Bugtracker. Umsetzung ist natürlich wie immer Seal
Team 6. Und der Effekt, der sich ganz schnell einstellt, ist, dass man merkt,
man hat ganz viele Bugs. Und das ist dann gleich das nächste Problem:
wir haben so viele Bugs, was machen wir jetzt?
Eine Sache, die ich inzwischen als Antipattern sehe, ist: Priorisieren von
Bugs. Ja, so eine übliche Umsetzung ist: man hat sowas wie „Severity: Blocker“
oder das ist ein Security-Bug – das soll hier eine Checkbox sein. Und der Effekt
davon ist, dass alle anderen Bugs liegen bleiben. Das kann man immer und immer
wieder beobachten. Also die… der eigentliche… was ich so beobachte, der,
der Effekt, der die meisten Bugs tötet, ist, wenn eine Komponente einfach
abgeschafft wird. Und dann kann man alles schließen in der Komponente.
Dass tatsächlich mal sowas weggeht, gibt es nicht.
*Applaus* Es gibt ein schönes Wort dafür, wo mir
jetzt die Übersetzungsteams bisschen leid tun, nämlich Bug-Welle, im Sinne von einer
Bugwelle vor so einem Tanker. Ich versuche das gerade mal zu etablieren, als Begriff.
Ich finde den nämlich sehr schön. So, also jetzt haben wir ganz viele offene Bugs,
was machen wir denn jetzt? Nächstes Problem. Und eine Idee, die häufig kommt,
und die auch erstmal total super klingt, ist, dass man bug-freien Code belohnt.
Und zwar am besten mit so einem Bonus, am besten in Geld. Wenn euer Team keine
offenen Bugs hat, dann werdet ihr belohnt. Und das führt eben dazu, das ist mir mal
passiert, dass ich so eine Mail gekriegt habe von einem Typ, wo ich ein paar Bugs
gefilet habe, und der kommt und meint: „Du Arschloch, jetzt ist mein Bonus weg. Ich
kann meine Hypothek nicht abzahlen!“ Und da wusste ich dann auch erstmal nicht
direkt, was ich dem sagen soll. Der hat das dann selbst gelöst, indem er alle Bugs
zugemacht hat und zwar mit NOTABUG. *Lachen*
Hat mir natürlich versprochen, dass die trotzdem alle gefixt werden. Aber das
könnt ihr euch ja vorstellen, wie gut das klappt. Also sowas ist sehr… ist sehr mit
Vorsicht zu genießen. Reward- und Incentives-Sachen am besten nicht mit
Geld. Es gibt auch ein Anti-Antipattern dazu. Nämlich habe ich mal erlebt, dass
jemand alle Bugs im Code gefixed hat, aber im Bugtracker waren die noch offen. Und
dann habe ich nicht verstanden, bin hingegangen, und dann hat er mir erklärt:
„Ja, die brauchen mich ja nicht mehr, wenn die Bugs zu sind.“
*Lachen und Applaus* Der hat halt gesehen, hat halt gesehen, um
ihn rum die Kollegen sind alle nach Indien abgeschoben worden, die Projekte, und
hat sich gedacht: „Na, die lass ich lieber offen, die Bugs, dann werde ich hier noch
ein paar Monate bezahlt.“ Das hat mir echt, das fand ich echt atemberaubend.
Da habe ich so ein paar Tage schlecht geschlafen. Weil das ist ja schon… was
für ein Selbstbild hat der denn, wenn er glaubt, irgendwie diese, diese Einträge im
Bugtracker halten ihn da am Leben? Ganz furchtbar. Aber das gibt es in kleineren
Ausmaßen häufiger, dass Leute Bugs offen lassen, weil sie wissen: wenn die Bugs weg
sind, dann kommt der Chef mit der nächsten To-Do-Liste. Und der einzige Weg, mal eine
Woche Luft zu haben, ist einfach, die Bugs nicht zu fixen. Das gibt es häufiger,
achtet mal darauf in eurer Firma, ob ihr das auch sehen könnt. Ich würde fast
wetten: ja. Das ist ein häufiges Pattern. Das ist auch ein Klassiker hier. Man hat
ein tolles Projekt, und das ist wunderbar, aber es funktioniert nur auf dem Rechner
vom Entwickler. Und die Idee ist: man hat jetzt einen Build-Server, ja? Wir haben
jetzt einen Build-Server, da wird gebaut, das ist eine neutrale Umgebung,
alles super. Seal Team 6 bastelt kurz was, und das sieht auch echt geil aus, ja?
Hier, so Drohnen-assistierte Baugeschichten. Aber übliche Sachen, die
halt fehlschlagen, ist, dass dieser Build- Server von dem Team ist, und baut halt den
Code von dem Team. Und die anderen Sachen werden aus irgendwelchen antiken Snapshots
von anderen Leuten reingezogen. Oder was ich auch mal gesehen habe: dass Libraries
dann so per SMB da reingelinkt werden. Und das ist natürlich totale Scheiße, ja?
Aber das passiert, so was passiert. Eine häufige Sache, die man auch sieht, ist,
dass man so einen Build-Server hat, aber da muss dann jemand hinlaufen und so
„Build“ klicken. Und das ist auch nicht schlau. Ich habe hier mal versucht, ein
Bild herauszusuchen. Die Idee beim Build-Server ist es, dass der am besten
automatisiert baut, und zwar mindestens einmal täglich. So, das habe ich auch
schon erlebt: der Build ist fehlgeschlagen, und dann hat der
Entwickler eben auf dem Build-Server angefangen, irgendwelche Dateien zu
editieren. Das ist jetzt gerade im Wachstum von Devops ein Problem, was wir
häufiger sehen werden, glaube ich. Das macht natürlich den Vorteil vom Build-
Server komplett kaputt, ja? Weil, dann habe ich wieder den Effekt, das ist ja der
Rechner vom Developer, aber es ist halt nicht mehr der unter seinem Tisch, sondern in
dem Rack da hinten, wo „Build-Server“ dransteht. So, ich hoffe, dass wir demnächst
ein Debian haben werden, was diese Namenskonvention übernimmt.
*Gelächter* Das sieht man auch häufig, ja, nicht nur
auf Build-Servern, sondern das wird halt irgendwann aufgesetzt und danach bleibt
das halt so. Und das hält das ganze Projekt zurück, weil dann irgendwelche
Software-Versionen da drauf sind. So übliche Sachen sind irgendwie eine SSL-Library,
die kein aktuelles TLS 1.2 kann. Und das werden wir mit 1.3 demnächst wieder haben,
das Problem. Oder irgendwie ein uraltes C++, und dann können die Leute die neuen
Features nicht benutzen. Also das ist alles ganz furchtbar. Will das mal hier
mit so einem schönen Müllhaufen illustrieren. Der Grund, warum man einen
Build-Server hat, ist, dass man täglich bauen kann, automatisiert, ohne dass da
jemand hingehen muss, und ohne dass jemand hingehen kann, um irgendwas zu fixen. Da
gibt es keine Interaktion außer: „Bau mal diese Version“, ja? Der Build soll
deterministisch sein. Das ist leider unabhängig vom Build-Server, muss ich euch
erzählen. Es gibt tatsächlich Build- Prozesse, da fällt jedesmal ein anderes
Binary raus, auch wenn man keine neue Version ausgecheckt hat, weil irgendwie
parallel gebaut wird und irgendwelche Dateien, die gebraucht werden, werden
asynchron von anderen Teilen aus dem Parallel-Build erzeugt. Und wenn man Glück
hat, kommt die richtige an. Und wenn man Pech hat, halt nicht. Also das muss man
fixen. Das ist Arbeit. Und es wäre mir sehr lieb, dass so Open-Source-Entwickler
auch alle dafür sorgen, dass ihre Projekte mit beliebiger Parallelität baubar sind.
Der nächste Grund für Build-Server ist Agilität.
*Applaus* Ja? Wenn ich irgendwas kaputtgemacht habe,
dann soll keine Panik ausbrechen, sondern dann sage ich „Rollback“ und bau halt die
Version von vorhin nochmal, die funktioniert hat. Wenn das nicht ein
Knopfdruck ist, dann könnt ihr den Build- Server auch wegschmeißen. Und natürlich
möchte man möglichst schnell mitkriegen, wenn jemand was eingecheckt hat, was den
Build bricht. Aber nicht sanktionieren! Ich habe mal so eine Firma erlebt, die hat
dann so ein Britney-Spears-T-Shirt gehabt, und das musste der Typ tragen, der den
letzten, zum letzten Mal den Build gebrochen hat.
*Lachen und Applaus* Macht das nicht. Das hat gut funktioniert,
bis sie so einen Britney-Spears-Fan als Angestellten hatten.
*Lachen* Ja. So, also das nächste Problem: ich habe
jetzt zwar einen Build-Server, und der baut das zwar unabhängig vom
Entwicklerrechner, aber das Binary funktioniert nur auf dem Rechner vom
Entwickler. Ist ein subtil anderes Problem, aber verwandt. Und das löst man
heute mit Docker, ist ja klar! *Applaus*
Und Docker ist im Prinzip keine schlechte Idee. Man darf halt nicht Seal Team 6
basteln lassen. Denn da kommen dann so Effekte wie: ich lutsche mir
irgendwelche Images von irgendwo aus dem Internet rein. Klassiker sind so Ramses-
der-Zweite-Debian und MySQL drei Punkt irgendwas von neunzehnhundert-äh.
So, dafür ist Docker nicht da. Docker ist gerade dafür da, dass das agil änderbar
ist. Und wenn ihr das nicht macht, dann ist es, als wenn ihr nicht lest. Könnt ihr
euch das gleich sparen. Also ich habe hier mal Frankenstein als Illustration
gebracht. Das bringt nichts. Dann habt ihr so ein Schrott-Projekt am Ende. Ich sehe
das häufig in der Industrie, dass die Leute alle Nachteile mitnehmen, aber die
Vorteile gezielt stehen lassen. *Lachen und Applaus*
Häufig gerade bei so Build-Systemen und Docker ist, dass man die Komponenten in
irgendwelchen statischen Versionen hart- codet, die halt aktuell waren, als es
aufgesetzt wurde, und danach nicht mehr geupdatet werden, ja? Also ich habe in den
letzten Jahren immer mehr Leute mit Build-Servern gesehen, die alles
automatisiert bauen. Und alle Dateien im Image haben so denselben Time-
Stamp grob. Also man sieht, dass es alles frisch gebaut wurde, aber es sind trotzdem
Versionen von 2004. Das ist sehr häufig, achtet darauf bei euch, ja? Und wenn ein
Zulieferer euch Kram gibt, der vom Build-Server kommt mit alten Versionen,
dann weist ihn darauf hin. Negatives Feedback. Das ist sonst wie so ein
Rollator: bremst nur. Container hat man für automatisiertes Deployment in
deterministischem Zustand. Das ist eine Sache, die haben fast alle verstanden.
Aber was nicht so verstanden wird, ist dieser, der Rollback ist eben auch
trivial, wenn man das mit so einem Docker- System baut. Dann klicke ich halt „Mach mal
die alte Version“ und dann fällt das Image der alten Version raus. Das ist ein
Feature, das ist nicht ein Seiteneffekt, sondern das ist einer der Gründe, warum
man das überhaupt hat. Nutzt das auch. Das ist nicht mehr… es tut nicht mehr weh,
wenn man was kaputtmacht im Build, sondern dann kann ich zurückrollen. Nicht
nur im Versionierungssystem, sondern ich kann auch einfach komplett, einen neuen
Build, fällt dann halt raus. Und am besten macht man sowas über die Mittagspause, ja?
Daher vorhin der Ratschlag, im Skript Abhängigkeiten testen. Und nicht nach zwei
Stunden den Build failen lassen. Docker ist… und Container sind
eigentlich eine gute Idee. Aber die meisten Leute nehmen nur die Nachteile
mit. Komponenten kann man agil updaten. Das muss man auch tun. Also ist hier keine
schwarze Magie, die ich hier erzähle. Aber es ist erstaunlich, wie viele Leute das
nicht machen. Und der mir als Security-Typ natürlich am wichtigsten erscheinende
Aspekt bei Containern ist, dass man damit Komponenten im Gesamtsystem isolieren kann
voneinander. Dass nicht ein Typ, der diesen einen Prozess hackt, automatisch
alle anderen im Zugriff hat. Sondern die laufen halt in ihren eigenen Containern.
Aber in der Praxis sieht man, dass dann der Monster-Container gebaut wird mit den
50 Komponenten drin. Das ist nicht gut. Also nehmt alle Vorteile mit. Richtig gut
ist das natürlich erst in Kombination, ja? Der Git hat alle Versionen und dem Build-
Server kann ich eine Version zurufen und dann fällt ein Image raus ohne
Abhängigkeiten. So, wenn ihr das nicht habt, dann benutzt ihr das nicht richtig.
Ganz einfach. Das nächste Problem ist: Der Code funktioniert nicht. Das kennen
wahrscheinlich auch alle, ist ein Problem. Was machen wir jetzt? Und die Lösung ist:
Unit-Tests! Und die Umsetzung ist häufig: ich habe hier gerade einen Bug, den fixe
ich mal, und den Check, ob der Bug weg ist, den mache ich jetzt als Unit-Test. Ja
und das ist nicht gut. Da kriegt man dann so eine Coverage von 2,3 Prozent, wenn es
hoch kommt. Und ich weiß nicht, ob ihr alle das Video hier gesehen habt. Das war
so ein Automat, der erkennen sollte, ob eine Hand drunter gehalten wurde. Und der
wurde halt von Weißen gemacht. Und die haben halt nie eine andere Hautfarbe
getestet. Und da kommt dann halt nix raus. So, das ist ein typischer Fall von „Unit-
Test-Abdeckung zu gering“. Ich glaube auch, dass hier die Perspektive die
falsche ist häufig. Die Leute glauben, sie machen Unit-Tests, damit sie wissen, dass
der Code jetzt okay ist. Nein! Unit-Tests sind dafür da, dass sich was ändern kann
und [man] sehen kann, ob es -noch- geht. Damit ich keine Angst mehr haben muss,
alten Code anzufassen. Das ist das, was Unit-Tests euch abnehmen: die Angst, in
altem Code was zu fixen. Weil ihr den nicht komplett versteht oder so. Und
je mehr Abdeckung ihr mit den Unit-Tests habt, desto stärker ist diese Waffe.
Nutzt das. *Applaus*
Ich muss hier ein bisschen durchgaloppieren, weil ich zu viele Folien habe. Ich hoffe,
das verzeiht ihr mir. So, das nächste Problem sind, dass die Leute nur positive
Tests haben. Die gucken: funktioniert das hier? Und der Effekt ist normalerweise so gut
wie keiner, denn die ganzen interessanten Bugs sind in der Fehlerbehandlung, dafür
braucht ihr auch Unit-Tests. Und zwar müsst ihr eigentlich für alles, was
fehlschlagen kann, einen Test haben, der das fehlschlagen lässt. Und dann gucken,
ob das immer noch funktioniert, wie es soll. Das sind die Sachen, die am Ende
über Bande woanders einen Fehler erzeugen, ja? Irgendwie eine Memory Corruption in
einem Fehlerfall, oder irgendwie „RAM wird nicht freigegeben im Fehlerfall“. Und dann
stellt sich raus: das kann man als Angreifer triggern. Und dann habe ich einen
Remote-Memory-Leak und der Prozess crasht. Diese Art von Sachen sind völlig überflüssig
und mit ordentlichen Unit-Tests abfangbar. Also macht das. Unit-Tests sind aber kein
Allheilmittel, den Eindruck möchte ich nicht vermitteln. Selbst wenn ich 100%
Unit-Test-Coverage habe, kann ich immer noch einen Fall übersehen haben.
Dennoch: das ist ein Ziel, was ihr haben solltet. Es gibt Tools, um die Coverage zu
prüfen. Nutzt diese Tools. Das ist wichtig. So, der nächste Fall, jetzt habe
ich Unit-Tests ausgerollt, ist: die Entwickler haben Fälle vergessen zu
testen, ja? Das kommt häufig vor. Und da gibt es einen neuen Hype: Test-
Driven-Development. Du schreibst erst die Tests und dann den Code. Und da kann ich
leider nichts zu sagen, weil ich das noch nie in der Produktion gesehen habe.
Ich kenne nur Leute…
*Lachen und Applaus*
Ich kenne nur Leute, die sich ganz sicher sind, dass das total geil ist. Aber ich
habe es noch nie… also wenn ihr da irgendwie wisst, dann schreibt mir mal
eine Mail, das würde mich echt interessieren. Ja, das nächste Problem
ist: wir haben hier Code, und der tut irgendwas, aber wir haben keine Ahnung,
wie das funktioniert. Und die Lösung ist natürlich: Dokumentation! Ist auch eine
gute Idee, das will ich keinem ausreden. Aber es kommt häufig vor, Seal Team 6
setzt ein Wiki auf, und da gibt es ganz häufig so Effekte – da werde ich hier
Congress-Teilnehmern nichts Neues erzählen – das Zertifikat ist gerade abgelaufen
oder das Wiki wirft Exceptions oder ist nicht erreichbar oder so. Das ist ganz
häufig. Und dann fallen so Sätze wie: „Ja, das hatte ich, glaube ich, ins Wiki getan“.
Und so: „Ja, das musst du halt bookmarken, weil Navigation haben wir noch nicht“. Und
ganz häufig gibt es auch: „Jaja, das hier oben, das stimmt nicht mehr“.
Also Wiki ist keine Lösung. Je kleiner man die Schwelle setzt dafür, da was zu
editieren, desto mehr fällt es unter den… vom Tisch. Weil die Leute
einfach das nicht als als wichtigen Schritt sehen, sondern als so kleines
Ding. Das muss ein richtiger Schritt im System sein, im Produktivbetrieb, dass
man sagt: „Jede Änderung wird dokumentiert, Punkt.“ So, die nächste Idee, die man in
großen Firmen häufig hört, dass man sagt: „Wir müssen hier mehr Kommunikation haben,
die Leute reden zu wenig miteinander“. Und dann hat man so Großraumbüros.
*Lachen und Applaus*
Habe ich auch noch nie funktionieren sehen.
Das klappt nicht, ja? Menschen müssen sich mal am Stück konzentrieren
können. Und je mehr Unterbrechung man hat, desto schlechter ist das. Und heute geht
der Trend sogar dahin…
*Applaus*
Heute geht der Trend sogar dahin, dass die Leute sich Slack installieren. Die
plakatieren gerade in Berlin. Also, die sich absichtlich gegenseitig unterbrechen.
Ist mir völlig ein Rätsel, warum Leute sowas tun würden. Denn nach jeder
Unterbrechung braucht man so eine Viertelstunde, bis man wieder drin ist.
Und diese Chatsysteme und auch Mail- Unterbrechungen sind darauf ausgelegt,
dass man nie diese 15 Minuten schafft. Ja, ich weiß, die Zeit ist knapp, ist gut!
*lacht* *Lachen*
Meetings, ja. Meetings. Da muss ich, glaube ich, nicht viel zu sagen.
Aber der Effekt ist immer derselbe: ich kann mich nicht konzentrieren. Und das
ist ein ernstes Problem. Da muss man aktiv gegenhalten,
ja? Das ist nicht so einfach. Ich habe jetzt überlegt: soll ich vorschlagen, die
Meetings kurz zu machen? Aber das ist so, habe ich auch nie funktionieren sehen, den
Ratschlag. Alle Leute glauben immer, sie machen ihre Meetings kurz. Funktioniert
nicht. Daher sage ich: lieber selten und One-on-One. Denn wenn man jetzt irgendein
Problem klären will, und da sitzen alle Leute aus dem Team, dann gibt es eine
höhere Schwelle für den Einzelnen, zu sagen: „Ja, da habe ich einen Fehler
gemacht.“ Deswegen lieber einzeln.
*Applaus*
Niemand, niemand hat Bock darauf, sich vor seinen Kollegen zu entblößen. Und das muss
man also nicht künstlich herbeiführen. So, jetzt kommen wir zur Security-Abteilung.
Wir haben Code und er tut irgendwas, aber wir trauen dem nicht. Was machen wir
jetzt? Nächste Idee: naja okay, wir machen erstmal die Compiler-Warnungen weg, ja?
Gute Idee. Der Effekt ist – und ich war schockiert, dass es da einen Begriff für
gibt: Onion-Code. So, Onion-Code bedeutet, dass ich so einen Chunk Legacy-Code habe,
der total viele Warnungen drin hat, und den seit fünf Jahren keiner mehr angefasst
hat. Und da findet jetzt jemand einen Bug drin. Und der würde den gerne fixen. Aber
dann compilet der Rest immer noch mit den ganzen Warnungen. Und die müsste ich dann
fixen, damit ich den Fix einchecken kann für den Bug. Und ich verstehe diesen Code
aber nicht. Ich verstehe nur den kleinen Teil, wo ich den Bug gefunden habe. Und
dann mache ich einen Layer drum rum, und der guckt diesen einen Fall, fängt ihn ab.
Und wenn das mehrere Leute machen, hat man so eine Zwiebel. Und deswegen heißt das
Onion-Code. Das ist ganz furchtbar, ja?
Wenn ihr das irgendwo seht, dann ‚burn it with fire‘!
So, nächster Vorschlag: wir haben nur noch Releases ohne offene Bugs. Das klingt auch
total super. Und ich war auch mal bei einem Kunden, der das probiert hat,
und da kam dann so eine Mail: „Mach mal deine Bugs alle zu.“ Und
dann meine ich so: „Ich bin aber hier, um Bugs aufzumachen, nicht um sie
zuzumachen.“ Und dann meinte er: „Ja, die machen wir danach wieder auf, keine
Sorge.“ *Lachen und Applaus*
Muss ich, glaube ich, nicht erläutern, ob die wieder aufgemacht wurden oder nicht.
Ja, externer Audit, und das tut mir in der Seele weh, denn das biete ich geschäftlich
an, ja, das ist leider auch teilweise ein Antipattern. Denn was hier passiert, ist,
dass die Leute so einen Blackbox-Pentest beauftragen. Und ein Blackbox-Pentest
heißt, der Tester hat keinen vollen Zugriff auf das System, der weiß nicht,
wie das funktioniert, sondern soll das in dem Test selber rausfinden. Und dann
passiert sowas hier. Und was mich an der Stelle am meisten beeindruckt hat, ist,
dass es dieses Bild schon gab. Das habe ich jetzt nicht gemacht. So, das ist
leider üblich. Man testet nicht den Code, sondern man testet den Pentester. Und ich
als Pentester habe jetzt natürlich… könnte jetzt sagen: „Ja, ist mir doch egal, wen
die da testen, solange ich bezahlt werde.“ Aber ich habe da so einen Moralkodex. Ich
hätte gern dem Kunden geholfen und nicht nur das Geld genommen. Das ist für alle
Seiten Scheiße. Macht das nicht. Ja, Pentests. Ich sage, das ist ein
Compliance-Problem, dass die Leute alle aus Compliance-Gründen Pentests machen.
Und das ist eigentlich an sich schon ein furchtbares Zeichen, dass wir die Security
nicht hinkriegen, sondern Compliance brauchen, um uns dazu zu bringen, dass wir
doch Security machen. Wir sollten uns alle schämen! Fuzzing ist auch so ein Ding. Das
wird gerne gemacht. Fuzzing heißt, dass ich zufällige Eingaben generiere und gegen
meinen Endpunkt werfe und gucke, ob der platzt oder nicht. Und das ist
erschütternd erfolgreich, ja? Das funktioniert. Und ich habe mal erlebt,
dass sie gesagt haben: „Nee, den Code hier, den musst du nicht testen, den haben
wir schon zu Tode gefuzzt. Seit Monaten läuft unsere Fuzzing-Farm.“ Und da stellt
sich dann heraus: die haben zwar Milliarden von Test-Cases geprüft. Aber
das war immer derselbe. *Lachen*
Total super. Und häufig ist Fuzzing so ein Feigenblatt, womit dann andere Maßnahmen
nicht gemacht werden, weil wir haben doch schon gefuzzt, und das ist auch in
Ordnung, ja? Also ich habe nichts gegen Fuzzing an sich, denn es funktioniert
leider. Aber es darf kein Hindernis dafür sein, andere wichtige Maßnahmen zu machen.
Das ist ein generelles Problem, was ich häufiger sehe, dass, wenn das Management
die Wahl hat zwischen einer Maßnahme, die wahrscheinlich funktioniert, aber keine
Metriken abwirft, und einer Maßnahme, die wahrscheinlich nicht funktioniert, aber
Metriken abwirft, dass immer die mit den Metriken gemacht wird. Management liebt
qualifizierbare Geschichten, wo irgend… quantifizierbare Geschichten, wo
irgendeine Zahl rausfällt. Und das geht häufig nach hinten los, ja? Ich habe also
mal so ein… das war ein wirklich schockierendes Erlebnis für mich. Ich bin,
ich sage mal preiswert, aber nicht billig, ja, also meine Tagessätze. – Ich weiß, ich
weiß! – So und dann gehe ich dahin, zu dem Kunden, und der Kunde sagt: „Geh mal nach
Hause.“ Also ich wurde trotzdem bezahlt, ja? Haben gesagt: „Geh mal nach Hause.“
Und ich so: „Wie jetzt?“ „Ja, ist warm heute.“ Meinte ich so: „Was?“ „Ja die
Klimaanlage reicht für das Fuzzing-Lab oder die Consultants.“
*Lachen und Applaus* Ja. Gut. Das nächste Problem, das ist so
ein bisschen schwierig. Aber es ist mir sehr wichtig, weil das so gerade im Kommen
ist. Die Coder sind überfordert. Und dann sagt man: wir brauchen irgendeinen soliden
Ansatz. Thread-Modeling! Das ist gerade im Kommen. Und das ist eine gute
Geschichte, aber es wird häufig missverstanden. Thread-Modeling, der
übliche Ansatz ist, dass man sagt: jedes Team macht ein Thread-Model für den Code.
Das ist gut. Ja? Aber häufig macht dann der Feature-Owner oder Projektmanager
mit dem Dokumentationsteam zusammen, füllt irgendwelche Formulare aus, und die
Developer sind überhaupt nicht betroffen. Und das ist ein krasser Fehler. Denn beim
Thread-Modeling geht es nicht um das Papier am Ende. Das ist kein Zertifikat.
Sondern es geht um den Weg zum Papier. Es geht darum, dass die Entwickler mal aus
der Sicht des Angreifers versuchen, auf ihren Code zu gucken, dass sie verstehen,
was da Angriffsoberfläche ist, dass sie sehen, wo die Sachen sind, auf die man
aufpassen muss, welche Angriffe denkbar sind. Wenn jemand anderes das Thread-Model
macht, das hätte man sich auch sparen können, ja? Also: Thread-Model ist gut,
aber das müssen die Entwickler machen. Wir sind fast durch. Ich habe noch ein paar
allgemeine Ratschläge, weil ich mir dachte: ich kann euch hier nicht so
deprimiert nach Hause gehen lassen. Aus Sicht des Management ist aus meiner Seite
ganz wichtig, dass man eine Fehlerkultur etabliert. Das heißt: niemand wird
bestraft für Bugs. Denn sonst verstecken die Leute Bugs, und das ist noch
schlechter, ja? Man muss Leute belohnen, …
*Applaus* Man muss Leute belohnen, wenn sie
einen Bug finden und fixen. Aber nicht mit Geld belohnen, sondern mit Ruhm und
Ehre. Ich schlage immer vor, einmal die Woche, irgendwie Freitag ab 4 oder so,
macht man so ein All-Hands-Meeting, wo – wenn die Leute wirklich was Anderes
vorhaben, müssen sie nicht hingehen, also kein Zwang – aber wo dann die alten
Hasen ihre schönsten Bugs erklären, ja? Damit es als etwas Positives gesehen wird,
einen Bug zu finden, und damit die Jungen was dabei lernen. Das ist eine gute Sache,
das kann ich empfehlen. Das funktioniert auch gut, und das bringt auch das Team
zusammen. Und es nimmt so diesen Rockstar- Status weg, der auch nur schadet. So, die
nächste Sache ist, dass man dafür sorgt, dass der Bug auch von dem gefixed wird,
der den Code geschrieben hat. Es gibt große Firmen, die teilweise ein zweites
Team dafür haben, Sicherheits-Bugs zu fixen. Und dann kriegt der Typ, der das
programmiert hat, überhaupt nicht mit, dass er die ganze Zeit schlechten Code
programmiert. Der zieht dann am besten noch so von Team zu Team, hinterlässt
überall so Tretminen. Das ist wichtig, dass es Feedback gibt. Und zwar nicht als
Strafe, sondern damit die Leute merken, wenn sie Fehler machen, ja? Menschen
lernen aus ihren Fehlern. Dafür muss man verstehen, wenn man einen Fehler gemacht
hat. Und das ist die, wo… komme ich zurück zu dieser Meeting-Kultur. Wenn man
ein Meeting hat und sagt: „Du hast hier aber Scheiße gemacht“, dann macht man den
vor dem ganzen Team nackig. Das hilft überhaupt nicht, ja? Man… es ist auch
eine Kulturkreis-Frage. Manche Kulturkreise können damit besser umgehen
als andere. Aber es gibt eben viele Leute, die haben ein starkes Problem damit, dass
ihnen gesagt wird: „Du hast einen Fehler gemacht“, ja? Weil das, in Japan zum
Beispiel ist es sehr wichtig, dass man der Firma hilft und nicht gesehen wird, wie
man irgendwie an irgendwas schuld ist. Also das ist schwierig, so etwas
aufzubauen. Aber das ist sehr wichtig. Fehler sind nicht schlecht, sondern aus
den Fehlern kann man lernen, ja? Fehler sind gut. Dann finde ich, dass die Firma
Werte kommunizieren sollte. Werte wie: uns ist der Code wichtiger, die Güte des
Codes ist wichtiger als die Quantität, ja? Es kommt nicht darauf an, hier mehr Kram
dran zu tun, sondern es kommt darauf an, dass wir, wenn wir was geschrieben haben,
da auch noch einmal darauf zurückkommen später, ja? Wenn wir was dazugelernt
haben, dass wir das auf den alten Code anwenden. Und damit das stressfrei machbar
ist, braucht man ordentliche Unit-Tests. So haben wir dann so einen Kreisschluss.
Die Anekdote, die ich hier erzählen wollte, war, dass ich mit einem Freund
einen Job hatte. Und da war… Teil von dem Problem war ein User-Interface. Und da
hatten wir beide überhaupt keine Ahnung von. Und der Freund meinte dann ganz
locker: „Ja lass uns das in Qt machen.“ Und ich meinte so: „Wir haben beide keine
Ahnung von Qt. Was machst du hier?“ Und da meint er: „Ja, das hätte ich gerne im
Resümee stehen, ja? Das muss… in meinem Lebenslauf sieht das gut aus.“ Das ist
schon ein paar Jahre her. Aber was ich sagen will: wenn die Firma den Leuten
nicht die Zeit gibt, Sachen zu lernen, dann lernen sie das in Projekten der
Firma, und die werden dann Scheiße.
*Applaus*
Was man auch häufiger sieht, ist, dass das Management glaubt, sie müsste die
Architektur der Software vorgeben, oder welche Datenbank verwendet wird oder so.
Und das ist eigentlich auch immer eine schlechte Idee. Denn entweder die
Architektur ist offensichtlich, dann hilft es nichts. Oder sie ist nicht
offensichtlich, dann sind die Ratschläge wahrscheinlich falsch, weil wir das
Problem noch nicht wirklich verstanden haben. Also das ist auch eine Sache, da
sollte sich das Management zurücknehmen an der Stelle.
*Applaus* Und hier noch so ein bisschen Selbsthilfe
für Entwickler. Ist die letzte Folie, ganz entspannt bleiben. Der Druck kommt immer
von euch selbst. Das Management kann viel erzählen, ja? Deadline hier, Deadline da.
Lasst euch da nicht dazu bringen, Überstunden zu fahren. Immer schön um 9
kommen, um 5 nach Hause gehen. Also… *Applaus*
Wenn unrealistische Anforderungen reinkommen, dann müsst ihr da ganz ehrlich
sein und sagen: „Das wird wahrscheinlich nicht klappen. Ich nehme jetzt euer Geld
und arbeite daran. Aber ich sage euch jetzt: das wird nix, ja?“ Immer schön
Paper-Trail hinterlassen, dass das nichts wird und man es rechtzeitig gesagt hat.
Man kann dann dran arbeiten, weil viele von euch werden wahrscheinlich die Kohle
brauchen, aber ehrlich sein, nicht so tun, als wenn wir das mit ein paar irgendwie
die-Nacht-durchgemacht am Ende noch reißen können. Das ist besonders in der
Spielebranche ein riesiges Problem, dass die Leute total Burnout kriegen. Man muss
das verstehen mit dem Management wie ein gegenseitiges Training, ja? Wenn ich dem
Management so etwas durchgehen lasse, dann zeige ich ihnen: das ist die neue
Baseline, ja? Das erwarten die ab dann.
Herald: Soll ich mir einen Stuhl holen, damit ich mich daneben setze?
Fefe: Kannst du machen, das ist die letzte Folie.
Herald: Okay. Fefe: Ganz ruhig!
So, und der letzte Satz, den ich habe: Zeit ist… muss man sich
selber nehmen, ja? Ich habe zwar gerade gesagt…
*Lachen und Applaus*
Herald: Raus mit dir! *weiter Applaus*
Ich habe zwar gerade dem Management empfohlen, euch Zeit zu geben,
aber wenn ihr darauf wartet, das wird nichts.
*Lachen* So, ich fürchte, die Fragezeit ist schon
vorbei, oder? Herald: Jo.
*Lachen und Applaus*
Das Beeindruckende ist ja wirklich: die sind alle da geblieben, und da ist
nicht einer vom Stuhl gefallen. Fefe: Ja! *lacht*
Herald: Vielen, vielen Dank! Ausgänge sind beide offen. Das war’s von Fefe.
Hier noch mal ein Applaus für ihn bitte!
*Applaus*
*Abspannmusik*
*Untertitel erstellt von c3subtitles.de im Jahr 2018*