34C3 - Antipatterns und Missverständnisse in der Softwareentwicklung

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