 Der Pfeffer hatte mich gebeten, mich kurz zu halten, weil er hat mir Angst, dass der Tork nicht in die 30 Minuten passt. Von daher gebe ich jetzt mal Gas und sage Antipäterns und Missverständnisse in der Softwareentwicklung. Und wie sagte jemand gestern, ach, Pfeffer, das ist doch der mit der Kolumne beim ehemaligen Nachrichtenmagazin. Here we go! Hallo, hallo, hallo, hallo. Ja, vielen Dank, dass ihr so zahlreich erschienen seid. Ein bisschen zahlreicher, als ich gedacht habe. Nächstes Mal mache ich doch lieber Paradil zu Min, korrekt wieder. Es geht um Antipäterns. Antipäterns 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 Kongress 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, demgegenüber, der es nicht kann. Die Struktur des Vortrags, die Struktur des Vortrags, da will ich an einem Beispiel kurz umreißen. Es geht immer damit los, dass wir ein Problem haben. Dann geht immer Zielteam Six los und hackt irgendwas. Also denkt euch hier ein Team von Spezialexperten. Ich weiß nicht, die Seels 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 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 Gemome, wenn die Leute zustimmen. Und ich dachte mir, wenn ich sage, hebt man den Arm, wenn euch das mal passiert ist, dann könnt ihr vielleicht Angst auf dem Stream zu landen und sich zu outen. Deswegen dachte ich, wir momeln mal. Also wenn einer von euch sich bei einem Muster wieder erkennt, könnt ihr mal versuchen, wir gucken mal, ob das klappt. Vielleicht hört man das dann. Also, erstes Problem. Dieses Bild, ich möchte das gleich dazu sagen, ist mir gespendet worden. Ich liefer hier keine Kunden ans Messer, und es geht nur um Anekdoten. Also wer sich glaubt wiederzuerkennen, liegt wahrscheinlich falsch. Das ist ein typisches Problem in der Softwareentwicklung, die Versionierung 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, was wird 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 Kunden gehabt, die meinten, es ist im Git, und dann meinte der Typ daneben, ja, ich muss noch sagen, in welchem, also das kommt vor. 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 Back, so was wie in dem Image sind, aber noch Set-Ure-Dibineries oder so was. Und dann machen die die alle weg, und dann installiert man die Nähte Version, und das sind wieder welche. Das hat man gemacht, aber hat halt ein Developer wieder reingemacht. Also Versionierung reicht noch nicht, da muss man noch mehr machen. Überhaupt die Idee, dass Leute Bineries einchecken, ist eine ganz schlechte. Das findet man immer wieder. Ich rede jetzt hier nicht von PNG oder irgendwie ein Impact von der Webseite oder sowas, sondern nur 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, 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 Antipäterns und meinen Ratschlag für Versionierungssysteme. Es geht schon in Ordnung. Ich bin mir der Ironie bewusst, dass meine eigene Software im Moment als TVS im Internet ist. Das hat historische Gründe. Patches hält man am besten klein, damit man sie einzeln anfassen kann, wenn sie nicht sauber üppleihen. Das ist ein Riesenproblem, wenn jemand so ein 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 nimmt 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 Bild in einem Script checken und nach zwei Stunden abbrechen, weil irgendwas nicht geklappt hat. So was möglichst vorher testen, damit es schnell reagieren kann. Es gibt häufig so die Idee in Firmen, dass man verschiedene Abteilungen hat und jeder hat ihr eigenes Versionierungssystem oder ein eigenes Repository. Das kann funktionieren, aber es ist sehr selten. Die Sache, die stimmen muss, damit es klappt, ist, dass die APIs stabil sind. Erfahrungsgemäß glauben alle, dass sie viel 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, wenn vergessen gefixt zu werden und offensichtlich die Lösung ist, wir machen so einen Backtracker. Umsetzung ist natürlich wie immer das Ziel-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. So eine übliche Umsetzung ist, man hat sowas wie Severity-Blocker oder das ist ein Security-Bug, das soll jeden Checkbox sein. Und der Effekt davon ist, dass alle anderen Bugs liegen bleiben. Das kann man immer und immer wieder beobachten. Also was ich so beobachte, der Effekt, der die meisten Bugs tötet, ist, wenn eine Komponente einfach abgeschafft wird. Und dann kann man alles schließen und das ist tatsächlich mal so was weggeht, gibt es nicht. Es gibt ein schönes Wort dafür, wo wir jetzt die Übersetzungsteam ein bisschen neigtun, nämlich Backwelle. 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 einen backfreien Kot belohnt. Am besten mit so einem Bonus, am besten in Geld. So, 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 hab von einem Typ, wo ich ein paar Bugs gefallt hab und da kommt mein Juarschloch. 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 hat mir natürlich versprochen, dass die trotzdem alle gefixt werden. Aber das könnt ihr euch hervorstellen, wie gut das klappt. Also, sowas ist sehr mit Vorsicht zu genießen. Reward und incentive Sachen, am besten nicht mit Geld. Es gibt auch ein Anti-Antipattern dazu, nämlich habe ich mal erlebt, dass jemand alle Bugs im Kot gefixt hat, aber im Backtracker waren die noch offen. Und dann habe ich nicht verstanden, bin hingegangen und dann hat er mir erklärt, die brauchen mich ja nicht mehr, wenn die Bugs zu sind. Der hat halt gesehen, um ihn rum. Die Kollegen sind alle nach Indien abgeschoben worden. Die Projekte und hat sich gedacht, lasse 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 er denn, wenn er glaubt, diese Einträge im Backtracker halten ihn da am Leben, ganz furchtbar. Aber das gibt es in kleineren, 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 die Idee ist, man hat jetzt ein Bild-Server. Wir haben jetzt ein Bild-Server, da wird gebaut, das ist eine neutrale Umgebung, alles super. Das sieht auch echt geil aus, hier so dronenassistierte Baugeschichten. Aber übliche Sachen, die halt fehlschlagen, ist, dass dieser Bild-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 wir da reingelingt werden. Und das ist natürlich totale Scheiße. Aber das passiert. So was passiert. Eine häufige Sache, die man auch sieht, ist, dass man so ein Bild-Server hat, aber da muss dann jemand hinlaufen und so Bild klicken. Und das ist auch nicht schlau. Ich habe hier immer versucht, ein Bild rauszusuchen. Die Idee beim Bild-Server ist, dass der am besten automatisiert baut. Und zwar mindestens einmal täglich. So, das habe ich auch schon erlebt. Ich habe mich auch schon auf den Bild-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 Bild-Server komplett kaputt. Weil dann habe ich wieder den Effekt, das ist der Rechner vom Developer, aber das ist halt nicht mehr der unter seinem Tisch, sondern in dem Rack dahinten, wo Bild-Server dran steht. So, ich hoffe, dass wir den nächsten Debian haben werden, was diese Namenskonvention übernimmt. Das sieht man auch häufig. Nicht nur auf Bild-Server, das wird halt irgendwann aufgesetzt und dann auch bleibt das halt so. Das hält das ganze Projekt zurück, weil dann irgendwelche Software-Versionen da drauf sind. So übliche Sachen sind, wie eine SSL Library, die kein aktuelles TLS 1.2 kann. Das werden wir mit 1.3 demnächst wieder haben, das Problem. Oder irgendwie eine uralte C++, und dann können die Leute die neuen Features nicht benutzen. Also das ist alles ganz furchtbar. Der Grund, warum man ein Bild-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 baumal diese Version. Der Bild soll deterministisch sein. Das ist leider unabhängig vom Bild-Server, muss ich euch erzählen. Es gibt tatsächlich Bildprozesse, da fällt jedes Mal ein anderes Binary raus, auch wenn man keine neue Version ausgecheckt hat, weil irgendwie parallel gebaut wird werden Asynchron von anderen Teilen aus dem Parallelbild erzeugt, und wenn man Glück hat, kommt die Richtige ein, 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 Bild-Server ist Agilität. Wenn ich irgendwas kaputt gemacht habe, dann soll keine Panik ausbrechen, sondern dann sage ich Rollback und halte die Version von vorhin noch mal, die funktioniert hat. Wenn das nicht ein Knopfdruck ist, dann könnt ihr den Bild-Server auch wegschmeißen. Und natürlich möchte man möglichst schnell mitkriegen, wenn jemand was eingeschickt hat, was den Bild 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 Mal den Bild gebrochen hat. Macht das nicht. Das hat gut funktioniert, wenn wir ihn als Angestellten hatten. Also das nächste Problem, ich habe jetzt zwar ein Bild-Server und der Baut ist zwar unabhängig vom Entwickler-Rechner, 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. Das ist ja klar. 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 lutsch mir irgendwelche Images aus dem Internet rein, Klassiker sind, so Ramses der Zweite der Bienen und MySQL 3.0 irgendwas von 1900. 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 Schrottprojekt am Ende. Ich sehe das häufig in der Industrie, dass man die Komponenten in irgendwelchen statischen Versionen hart kodet, die halt aktuell waren, als es aufgesetzt wurde und danach nicht mehr geupdatet werden. Also ich habe in den letzten Jahren immer mehr Leute mit Bild-Saubern gesehen und die alles automatisiert bauen und alle Dateien im Image haben so denselben Timestamp grob. Also man sieht, dass es alles frisch gebaut wurde, aber es sind trotzdem Versionen von 2004. Das ist sehr häufig auch so. Das ist sehr häufig auch so, dass man die Komponenten automatisiert haben kann. Das ist sehr häufig. Achtet darauf bei euch. Und wenn Ihnen ein Zudieferer euch Kram gibt, der vom Bild-Sauber kommt mit alten Versionen, dann weist ihn drauf hin. Negatives Feedback. Das ist sonst wie so ein Rollator und 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 wurde, ist eben auch trivial. Wenn man das mit so einem Docker-System baut, dann klick ich halt und 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. Es tut nicht mehr weh, wenn man was kaputt macht im Bild, sondern dann kann ich zurückrollen. Nicht nur im Versionierungssystem, sondern ich kann auch einfach vorhin der Ratschlag im Skriptabhängigkeiten testen und nicht nach 2 Stunden den Bild fehlen lassen. Docker-Issen 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. Es 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 am wichtigsten erscheinende Aspekt ist, dass man damit Komponenten im Gesamtsystem isolieren kann voneinander. Dass dich ein Typ, der diesen einen Prozess hackt, automatisch alle anderen im Zugriff hat, sondern die laufen 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. Der Git hat alle Versionen zu veröffentlichen. Das ist ein Problem, was wir jetzt machen. Die Lösung ist Unit-Tests. Die Umsetzung ist häufig, ich habe hier gerade einen Bug, den fix ich mal und den check, ob der Bug weg ist, den mache ich jetzt als Unit-Test. Das ist nicht gut. Da kriegt man dann so eine Coverage von 2,3% wenn es hochkommt. Das ist nicht gut. Das ist nicht gut. Das ist nicht gut. Ich weiß nicht, ob ihr das Video hier gesehen habt. Das war ein Automat, der erkennen sollte, ob eine Hand runtergehalten wurde und er wurde halt von weißem gemacht. Die haben halt nie eine andere Hautfarbe getestet und da kommt dann halt nichts raus. Das ist ein typischer Fall von Unit-Test-Abdeckungen 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. Sie wissen dafür da, dass sich was ändern kann und sehen kann, ob es noch geht. Damit ich keine Angst mehr habe, 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 Abdeckungen ihr mit den Unit-Tests habt, desto stärker ist diese Waffe. Nutzt das. Ich muss hier ein bisschen durchgaloppieren, weil ich zu viele Folien habe. Ich glaube, dass die Leute nur positive Tests haben. Sie gucken und funktioniert das hier. Und der Effekt ist normalerweise so gut wie keiner, denn die ganzen interessanten Backs 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 ein Fehler erzeugen. Wenn man eine Reaktion 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 ein Remote-Memory-Leak und der Prozess crashed. Diese Art von Sachen sind völlig überflüssig und mit ordentlichen Unit-Tests abfangbar. Also macht das. Unit-Tests sind aber kein Allheimittel. Den Eindruck möchte ich nicht vermitteln. Selbst wenn ich 100% Unit-Test-Coverage hab, kann ich immer noch einen Fall übersehen haben. Dennoch, das ist ein Ziel, und das sind die Tools. Das ist wichtig. Der nächste Fall, jetzt habe ich Unit-Tests ausgerollt, ist die Entwickler haben Fälle vergessen zu testen. 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, die sich ganz sicher sind, dass das total geil ist. Ich hab mir immer eine Mail. Das würde mich echt interessieren. 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. Das ist auch eine gute Idee. Das würde ich keinem auswähnen, aber es kommt halt häufig vor. Zielteams 6 setzen Wiki auf. Und da gibt es ganz häufig so Effekte. Da werde ich hier Kongressteilnehmer nichts Neues erzählen. Das Zertifikat ist gerade abgelaufen. Oder das Wiki wirft exceptions oder so, das ist ganz häufig. Und dann fallen so Sätze wie, das hatte ich glaube ich ins Wiki getan. Das musste halt bookmarken, weil Navigationen haben wir noch nicht. Und ganz häufig gibt es auch, dass hier oben das stimmt nicht mehr. Also Wiki ist keine Lösung. Je kleiner man die Schwelle setzt dafür, da was zu editieren, dass so mehr fällt, das unter dem Tisch. Weil die Leute einfach das nicht als wichtigen Schritt sehen, das ist so ein kleines Ding. Das muss ein richtiger Schritt im System sein, im Produktivbetrieb, dass man sagt, jede Änderung wird dokumentiert, Punkt. 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ßraum-Büroß. Habe ich auch noch nie funktionieren sehen. Das klappt nicht. Menschen müssen sich mal ein Stück konzentrieren können. Und je mehr Unterbrechungen man hat, dann ist es so. Und 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 so was tun würden. Denn nach jeder Unterbrechung braucht man so eine Viertelstunde, bis man wieder drin ist. Und diese Chat-Systeme und auch Mail-Unterbrechungen sind darauf ausgelegt, dass man nie diese 15 Minuten schafft. Ja, ich weiß, die Zeit ist knapp, ist gut. Ja, dann muss ich glaube ich nicht viel zu sagen. Aber der Effekt ist immer derselbe. Ich kann mir nicht konzentrieren. Und das ist ein ernstes Problem. Da muss man aktiv gehen halten. Das ist nicht so einfach. Ich habe jetzt überlegt, soll ich vorschlagen, die Meetings kurz zu machen. Aber das ist so, ob ich auch noch nicht funktionieren sehe in den Ratschlag. Alle Leute glauben immer, sie machen ihre Meetings kurz. Es funktioniert nicht. Daher sage ich lieber selten. Wenn man jetzt irgend ein 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, da habe ich einen Fehler gemacht. Deswegen lieber einzeln. Niemand hat Bock darauf, sich vor seinen Kollegen zu entblößen. Das muss man also nicht künstlicher beiführen. Jetzt kommen wir zur Security-Abteilung. Wir haben Code und er tut irgendwas, aber wir trauen ihm nicht. Was machen wir jetzt? Nächste Idee. Gute Idee. Der Effekt ist, und ich war schockiert, dass es Begriffe gibt. Onioncode. Onioncode bedeutet, dass ich ein Chunk Legacy Code habe, der total viele Warnungen drin hat und den seit fünf Jahren kann er mir angefasst haben. Da findet jetzt jemand ein Back drin. Der würde ihn gerne fixen, aber dann kompile der Rest immer noch mit den ganzen Warnungen. Die müsste ich dann fixen, damit ich den Fix einschenken kann und dann mache ich einen Layer drumherum. Und der guckt diesen einen Fall, fängt den ab. Wenn das mehrere Leute machen, hat man so eine Zwiebel. Deswegen heißt das Onioncode. Das ist ganz furchtbar. Wenn ihr das irgendwo seht, dann burn it with fire. Nächster Vorschlag. Wir haben nur noch Release ohne offene Bugs. Das klingt auch total super. Ich habe auch mal beim Kunden, der das probiert hat. Ich bin aber hier, um Bugs aufzumachen, um sie zuzubachen. Und der meinte, ja, die machen wir danach wieder auf. Muss ich nicht erläutern, ob die wieder aufgebracht wurden oder nicht. External Audit. Das tut mir in der Seele weh, denn das biete ich geschäftlich an. Das ist leider auch teilweise ein Anti-Pettern. Was hier passiert ist, dass die Leute so einen Blackbox-Pen-Test beauftragen. Ein Blackbox-Pen-Test heißt, der Tester hat keinen vollen Zugriff auf das System. Man kann das in dem Test selber rausfinden. Und dann passiert so was hier. Und was mich an der Stelle am meisten beeindruckt hat, ist, dass es dieses Bild schon gab. Das habe ich jetzt nicht gemacht. Das ist leider üblich. Man testet nicht den Coats, sondern man testet den Pen-Tester. Und ich als Pen-Tester habe jetzt natürlich, ich könnte jetzt sagen, ja, ich bin auch egal, wen die da testen, solange ich bezahlt werde. Aber ich habe da so einen Moral-Codex. Ich hätte gerne dem Kunden geholfen und nicht nur das Geld genommen. Ich sage, das ist ein Compliance-Problem, dass die Leute alle aus Compliance-Grunden-Pen-Tests 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. Fashing ist auch so ein Ding, das wird gerne gemacht. Fashing heißt, dass ich zufällige Eingaben generiere und gegen meinen Endpunkt werfe und das ist erschütternd erfolgreich. Ja, das funktioniert. Und ich habe mal erlebt, dass die gesagt haben, den Kot hier, den musste ich nicht testen. Den haben wir schon zur Tode gefasst. Seit Monaten läuft unsere Fashing-Farm und da stellt sich dann raus, die haben 2 Milliarden von Testcases geprüft, aber das war mal derselbe. Total super. Und häufig ist Fashing so ein Feigenblatt, womit dann andere Maßnahmen nicht gemacht werden, weil wir haben doch schon gefasst und das ist doch in Ordnung. Das ist 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 es 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, und das geht häufig nach hinten los. Ich habe also mal so ein, das war ein wirklich schockierendes Erlebnis für mich. Ich bin, ich sag mal, preiswert, aber nicht billig, als kommt meine Tagessätze. Ich weiß nicht was. So, und dann gehe ich dahin zu dem Kunden und der Kunde sagt, geh mal nach Hause. Also ich wurde trotzdem bezahlt. So gesagt, geh mal nach Hause, nicht so wie jetzt. Ja, es warben heute. Ja, die Klimaanlage reicht als fassigen Lab oder die Consultants. 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 einen soliden Ansatz, Fredmodeling. Das ist gerade im Kommen, und das ist eine gute Geschichte, aber es wird häufig missverstanden. Fredmodeling, der übliche Umsatz ist, dass man sagt, jedes Team macht ein Fredmodel oder eine Corona- oder Projektmanager mit dem Dokumentationsteam zusammenfüllt, irgendwelche Formulare aus, und die Developer sind überhaupt nicht betroffen. Und das ist ein krasser Fehler, denn beim Fredmodeling 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 Kurs zu gucken, dass sie verstehen, was der Angriffsoberfläche ist, dass sie sehen, wo die Sachen sind, auf die man aufpassen muss, welche Angriffe denkbar sind. Wenn jemand anders das Fredmodel macht, das hätte man sich auch sparen können. Also, Fredmodel 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 Bax, denn sonst verstecken die Leute Bax, und das ist noch schlechter. Man muss Leute belohnen, wenn sie einen Bug finden und fixen, aber nicht mit Geld belohnen, sondern mit Rum und Ehre. Ich schlage immer vor, einmal die Woche, irgendwie Freitag ab vier oder so, macht man so ein All Hands Meeting, wo, wenn die Leute wirklich was anderes vorhaben, müssen sie nicht hingehen, also keinen Zwang. Aber, wo dann die alten Hasen ihre schönsten Bax erklären. Damit es als etwas Positives gesehen wird, ein Bug zu finden und was dabei lernen. Das ist eine gute Sache, das kann ich empfehlen, das funktioniert auch gut. Das bringt auch das Team zusammen und es nimmt so diesen Rockstar-Status weg, der auch nur schadet. Die nächste Sache ist, dass man dafür sorgt, dass der Bug auch von dem gefixt wird, der den Code geschrieben hat. Es gibt große Firmen, die teilweise ein zweites Team dafür haben, Sicherheitsbugs zu fixen. Dann kriegt der Typ, der das programmiert hat, auch so von Team zu Team, hinterlässt überall so Tretenminen. Das ist wichtig, dass es Feedback gibt. Und zwar nicht als Strafe, sondern damit die Leute merken, wenn sie Fehler machen, Menschen lernen aus ihren Fehlern, dafür muss man verstehen, wenn man Fehler gemacht hat. Und das ist die, wo komme ich zurück zu dieser Meeting-Kultur, wenn man Meeting hat und sagt, du hast hier aber Scheiße gemacht, dann macht man den vor dem ganzen Team nackig. Aber es gibt viele Leute, die haben ein starkes Problem damit, dass ihnen gesagt wird, du hast ein Fehler gemacht. In Japan ist es sehr wichtig, dass man in der Firma hilft und nicht gesehen wird, wie man an irgendwas schuld ist. Das ist schwierig, so was aufzubauen, aber das ist sehr wichtig. Fehler sind nicht schlecht, sondern aus den Fehlern kann man lernen. Fehler sind gut. Dann finde ich, wie uns ist der Code wichtiger, die Güte des Kodes ist wichtiger als die Quantität. Es kommt nicht darauf an, mehr Kram dran zu tun, sondern es kommt darauf an, dass wir, wenn wir was geschrieben haben, da auch noch mal darauf zurückkommen später. Wenn wir was dazu gelernt haben, dass wir das auf den alten Code anwenden. Und damit das stressfrei machbar ist, braucht man ordentliche Unitests, so haben wir einen Kreisschluss. Die Anekdote, die ich hier erzählen wollte, hatte einen Job. Teil von dem Problem war ein User-Interface. Da hatten wir beide keine Ahnung von. Der Freund meinte ganz locker, lass uns das in Qt machen. Wir haben keine Ahnung von Qt, was machst du hier? Er meinte, das hätte ich gerne im Risiko stehen. Das ist schon ein paar Jahre her, aber wenn die Firma den Leuten nicht die Zeit gibt, Sachen zu lernen, dann lernen sie das in Projekten der Firma. Die werden dann scheiße. Was man auch häufiger sieht, ist, dass das Management glaubt, sie müsste die Architektur der Software vorgeben oder welche Datenbank verwendet wird. 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. 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 dann nicht dazu bringen, über Stunden zu fahren. Immer schön um 9.00 Uhr kommen, um 5.00 Uhr nach Hause gehen. Also, 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 nichts. Immer schön Paper Trail hinterlassen, dass es nichts wird und man es rechtzeitig gesagt hat. Man kann dann daran arbeiten, weil viele von euch werden wahrscheinlich die Kohle brauchen. Aber ehrlich sein, nicht so tun, als wenn wir das mit ein paar 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 es verstehen mit dem Management wie ein gegenseitiges Training. Wenn ich dem Management so etwas durchgehen lasse, dann zeige ich Ihnen, das ist die neue Baseline. Das ist die letzte Folgen. Soll ich meinen Stuhl holen? Kannst du machen, das ist die letzte Folgen. Okay, ganz ruhig. Der letzte Satz, den ich habe, Zeit ist, muss man sich selber nehmen. Ich habe zwar gerade gesagt, ich habe zwar gerade den Management im Fohlen euch Zeit zu geben, aber wenn ihr darauf wartet, das wird nichts. Ich fürchte, die Frage Zeit ist schon vorbei. Mir ist ja wirklich, die sind alle da geblieben und da ist nicht einer vom Schuh gefallen. Vielen, vielen Dank. Ausgänge sind beide offen. Das war es vom Fefe. Hier nochmal ein Applaus für Ihnen, bitte.