Legacy Code - aber ganz sicher

Jetzt habe ich sie ganz deutlich gespürt: eine Hürde für die Verbesserung der Softwareentwicklung.

Neulich hatte ich über die Clean Code Developer School ein Angebot gemacht: Kostenlose Hilfe beim Frühjahrsputz der Codebasis. Warum nicht mal im Legacy Code aufräumen, wenn die Sonne anfängt zu lachen? Und zu zweit macht das Refaktorisieren noch mehr Spaß. Vier Augen sehen auch mehr Schmutz im Code als zwei.

Als ich nun mit einem Bewerber für die Aktion den ersten Termin absprechen wollte, schrieb der alsbald, dass sein Datenschutzbeauftragter fordere, dass ich eine Geheimhaltungsvereinbarung unterzeichne. O-Ton:

"Wir müssen natürlich sicherstellen, dass keine Informationen das Unternehmen verlassen, bzw. der Quellcode und Kunden-/Unternehmensdaten sicher sind."

Hört sich das für Sie normal und harmlos an? Für mich nicht. Ich zucke dabei innerlich zusammen.

Da hilft auch keine weitere Erklärung:

"[...] stellen [Geheimhaltungsvereinbarungen] für unser Unternehmen auch eine rechtliche Absicherung für den Fall dar, dass es zu Datenlecks kommt."

Denn: Was soll abgesichert werden? Ich verstehe das nicht.

Aber ich will versuchen, mich in die Situation hineinzuversetzen:

Der Entwickler des Unternehmens, der sich um Frühjahrsputzunterstützung beworben hat, arbeitet mit mir online im Pair. Ich schaue über Screensharing auf seinen Rechner in die IDE. Wir arbeiten an seinem Legacy Code.

Wo sind da Unternehmensdaten, die nicht nach außen dringen sollen? Achja, der schlichte Fakt, dass es dort im Unternehmen überhaupt solchen immer schwerer wartbaren Code gibt, ist natürlich etwas Geheimhaltungswürdiges. Da geht's schon los. Ich dürfte ja nie verraten, um welches Unternehmen es sich handelt, das da so tief im Brownfield watet. Davor hat das Unternehmen sicher zurecht Angst.

Oder vielleicht blitzen auf dem Desktop des Entwicklers auch Dokumente auf, die geheimhaltungswürdige Informationen enthalten. Wenn der dann mal eine Pinkelpause macht, nutze ich die Gunst der Stunde und sehe diese bestimmt leicht identifizierbaren Dokumente schnell mal ein oder lade sie gar herunter. Natürlich, um damit bei den zahlreichen Wettbewerbern des Unternehmens hausieren zu gehen.

Oder es könnte sein, dass im Code Featuretoggles zu erkennen sind, die nur für bestimmte Kunden gelten. Das könnte ich auch verraten. Hehe.

Oder wir schauen en passant mal in der Datenbank mit ihren 700 eng verzahnten Tabellen vorbei und ich mache Screenshots von darin gespeicherten Kreditkartennummern (inklusive Namen und Sicherheitscodes), vielleicht stehen auch irgendwo noch unverschlüsselte Passworte. Damit ließe sich bestimmt ein hübsches Sümmchen verdienen.

Nein, so würde es natürlich nicht gehen. Der Datenschutzbeauftragte hat selbstredend ein wachsames Auge auf die Programmierpraktiken der Entwickler. Solche Sicherheitslecks würde es dort nicht mal geben. Aber ich könnte einen Blick auf Kundendaten erhaschen. Dass jemand dort Kunde ist und was er dort als Kunde tut, ist bestimmt auch im Vorbeigehen leicht zu überblicken und zu kopieren und dann in mich bereichernder oder den Kunden schädigender Weise verwendbar. Hehe, hehe.

So stellt sich das der Datenschutzbeauftragte, nein, die Geschäftsleitung, die den Datenschutzbeauftragten beauftragt hat, bestimmt vor. Die Welt ist ein übler Ort. Das Böse ist immer und überall. Und wenn nicht das Böse, dann die Fahrlässigkeit oder Ignoranz. Vor allem bei Externen.

Und dagegen – das ist ja sonnenklar – hilft... eine Geheimhaltungsvereinbarung. Denn dann passiert das alles nicht. Nie. Weil mir natürlich nach der Unterschrift die Knie schlottern ob der Strafbewehrung. Der Kragen wird mir dann ganz eng und ich realisiere, wie vorsichtig, vorsichtig ich sein muss, wenn ich auf den Bildschirm des Kunden schaue. Bloß nichts memorieren! Und wenn, dann noch vorsichtiger in Zukunft sein, dass mir von dem, was ich noch erinnere, nichts über die Lippen kommt. Oder vom Laptop auf ein Speichermedium rutscht, das den Weg in eine Redaktion oder zum Wettbewerber oder auf Facebook findet.

Das war mir vorher natürlich überhaupt nicht klar. Ohne Geheimhaltungsvereinbarung hätte ich wahrscheinlich einen Livestream der online Sitzung geschaltet für alle Software Craftsmen zum über die Schulter schauen. Aber nun, nach Unterschrift... da wäre alles anders.

Merkt denn kein Datenschutzbeauftragter, wie lächerlich das ist? (Oder geht hier irgendeine Tragweite und Gefahr völlig an mir vorbei?)

In der aktuellen Ausgabe des Objektspektrum lese ich gerade von Prof. Gerd Gigerenzer die Formulierung "In unserer wachsenden Absicherungskultur..." Das passt wie die Faust auf's Auge. Genau das ist hier nämlich am Werk: eine Absicherungskultur.

Zusammenarbeit beginnt mit Misstrauen. Wer ohne Ansicht der Sache – hier: online Refactoring-Sitzung – pauschal eine Geheimhaltungsvereinbarung fordert, der stellt sein Gegenüber unter Generalverdacht.

Eine Selbstverständlichkeit, dass man unter Geschäfts-/Kooperationspartnern das Gesprochene vertraulich behandelt, gibt es nicht (mehr).

Auch eine explizite Bitte, die in einer Email sogar dokumentiert werden könnte (und die zumindest dort sicherlich revisionssicher abgelegt wird), ich möge doch alles, was ich sehe/höre vertraulich behandeln, genügt nicht.

Nein, es müssen 1,2,3 Seiten hochoffizieller Geheimhaltungsvereinbarung her. Mit der hat sich eine Rechtsabteilung befasst, die muss archiviert werden und: Die muss ich vor allem erstmal in ihrer Tragweite verstehen. Ohne Rechtsberatung auf meiner Seite kann ich das aber nicht leisten. Für das kostenlose Angebot müsste ich also mal mindestens für 30 Minuten Anwaltskosten aufbringen.

Das ist unverhältnismäßig. Das ist nicht auf Augenhöhe. Das ist nichts, was eine flüssige, vertrauensvolle Zusammenarbeit fördert.

"Aber das Vertrauen kann doch nur entstehen, wenn mann sich sicher sein kann, dass der andere nichts Böses tut. Das erreicht eine Geheimhaltungsvereinbarung." So lautet bestimmt die Rationalisierung des Datenschutzbeauftragten.

Ich erlaube mir jedoch, anderer Meinung zu sein. Vertrauen entsteht nicht durch einen Vertrag, sondern durch Verlässlichkeit. Wenn ich jemandem nicht vertraue, dann arbeite ich mit ihm nicht. Oder ich wage mich nur so weit vor, wie es mir bei Unzuverlässigkeit nicht schaden würde. Das ist normal und menschlich.

Eine Geheimhaltungsvereinbarung hingegen setzt sich über solch natürliches Vorgehen hinweg und versucht, eine unnatürliche Effizienz herzustellen. Man macht einen größeren Schritt als das eigene Vertrauen zulässt. Das bedeutet, man arbeitet im Misstrauen zusammen.

Kann das bekömmlich sein?

Kurzfristig vielleicht. Langfristig halte ich das für kontraproduktiv. Denn Misstrauen unterliegt auch dem Bestätigungsfehler (confirmation bias). Wenn ich misstraue, dann finde ich eher mein Misstrauen Bestätigendes. Ich stehe also dem Vertrauensaufbau tendenziell entgegen.

Daraus folgt: Ich tendiere dazu, mich noch mehr abzusichern. Und noch mehr. Nach außen, nach innen.

Ob das wirklich etwas bringt, außer Verwaltungsaufwand, ängstlicher Atmosphäre und reziprokem Misstrauen, ist natürlich völlig unklar. Ich erfahre ja nicht, wie es ohne das Misstrauen wäre. Also muss ich glauben, dass ausbleibendes Drama kausal auf diese Absicherung zurückzuführen ist. Die Selbstbestätigung der Absicherungsmentalität ist die Folge.

Klar, so kann man leben. Nur muss man eben auch die Konsequenzen tragen. Hier: Der Legacy Code ist ganz sicher. Sicher in zweierlei Hinsicht: sicher verwahrt und sicher auch noch auf lange Zeit existent.

Da sehe ich tatsächlich einen Zusammenhang, der natürlich dem Datenschutzbeauftragten nicht klar ist.

Dass in dem Unternehmen das Brownfield bis zum Halse steht und vor allem aus Code einer Programmiersprache besteht, die Cobol wohl einmal den Rang ablaufen wird, ist für mich kein Wunder. Absicherungsmentalität – zumindest wie gemeinhin gelebt – kann nicht anders, als am Alten festzuhalten, bis es nicht mehr geht. Neues ist einer Absicherungsmentalität tendenziell unangenehm. Neues ist unbekannt; Unbekanntem kann man kein Vertrauen entgegenbringen; also muss eine Garantie her, dass das Unbekannte keinen Schaden anrichtet. Die Garantie – die natürlich nie eine ist – besteht dann aus Verträgen und Beweisen.

Und am Ende ist das Eigentliche, die Sache, der Kunde zweitrangig. Dann ist Absicherung wichtiger. Das ist das Gegenteil von Agilität. Deshalb sehe ich in diesem Fall einen Bestätigung (klar, auch ich falle dem confirmation bias zum Opfer) für meine These der "Agile Organization Illusion": nicht jede Organisation kann so agil werden, wie sie scheinbar möchte.

Hier ist es ja offenkundig: der vom Entwickler geäußerte Wunsch nach Verbesserung kann nicht erfüllt werden. Die aus der Organisations-DNA geborene Geheimhaltungsvereinbarung steht dem im Wege. Denn ich unterschreibe sie nicht.

Andere unterschreiben sie natürlich. Das Unternehmen kann sich woanders Unterstützung suchen. Aber damit ist das Grundproblem ja nicht behoben. Die Geheimhaltungsvereinbarung selbst ist ja nicht das Problem. Sie ist nur ein Symptom für das wahre Problem: Absicherungs- und Misstrauenskultur.

Ich finde das tragisch. Denn die einzelnen Menschen im Unternehmen wollen ja das Gute. Der Entwickler ist ehrlich an der Verbesserung des Codes interessiert. Auch der Datenschutzbeauftragte hat einen grundsätzlich wichtigen Job in der heutigen Zeit. Trotzdem wird nicht das Beste erreicht. Sehr schade.

Es wird an Stellvertreterschauplätzen gekämpft, z.B. mit mir als kleinem Dienstleister, der mal über die Schulter schaut.

Doch was ist eigentlich mit echten Risiken für Lecks? Was ist eigentlich mit dem Code? Hat der Datenschutzbeauftragte eine Ahnung, welches Datensicherheitsproblem Legacy Code darstellen kann?

Er hat Angst davor, dass Code das Unternehmen verlässt. Wie lächerlich! Code, den die eigenen Entwickler kaum mehr verstehen, ist für andere ohne Anleitung gar nicht mehr verständlich. Der Code könnte in vollem Umfang auch bei Github in einem öffentlichen Repo liegen und nichts würde passieren. (Naja, vielleicht gäbe es "überraschte" Kommentare ob des Brownfields.)

Wie steht es mit Regressionen? Macht der Datenschutzbeauftragte sich Gedanken darüber, dass durch unübersichtlichen Code und Regressionen Daten falsch gespeichert, falsch zugeordnet oder gar gelöscht werden könnten? Was ist mit unvollständigem Verständnis der Domäne und des Codes durch Kommunikationsprobleme innerhalb des Teams aufgrund von Kultur- und Sprachdifferenzen? Liegt darin kein Risiko, dass Code entsteht, der Daten leckt? Mitarbeiterverträge sichern dieserlei nicht ab.

Aber nun genug. Mir gehts um die Verhältnismäßigkeit. Ich kenne auch das Muster: lieber ein (vermeintliches) Problem lösen, das ich verstehe, als ein echtes und großes. Das scheint mir hier pars pro toto auch am Werk.

Schade. Ich hätte gern meine Zeit verschenkt, um bei der Säuberung des Codes zu unterstützen. (Naja, hoffentlich hätte ich dabei auch etwas gelernt.) Aber nicht unter diesen Umständen. Ohne Vertrauen habe ich keine Lust zu arbeiten. Auch wenn ich zugezogener Hamburger bin, finde ich das Hamburger Kaufsmannsbild erhaltenswert: man geht eine Kooperation per Handschlag ein. Das kann man, weil man ein Wertesystem teilt. Zu dem gehört natürlich auch Vertraulichkeit.