Ich habe früh in meinem Leben mit Softwareentwicklung angefangen. Ich erinnere mich noch, wie ich in den 80er Jahren Weihnachtslieder in GW-BASIC programmiert habe, und eine sehr coole Benutzeroberfläche gebaut habe, bei der man mit den Pfeiltasten in einem Menü herumnavigieren konnte. Auf unserem Monochrom-Bildschirm in 80x25 sah das verdammt cool aus. Viel cooler als ein Großteil der anderen Software, die wir so im Einsatz hatten. Damals wie heute nagte der Gedanke in mir, irgendwo könnte das irgendjemand irgendwo besser können als ich. Also nicht im Sinne von: Der hat mehr Zeit investiert und mehr Erfahrung und ist daher effizienter. Nein. Besser im Sinne von: Wenn der sähe, wie ich hier herumkrautern muss, um zu meinen Ergebnissen zu kommen, dann würde der ein lautes Lachen nur mit Mühe unterdrücken können.
Besonders ausgeprägt ist diese Befürchtung immer in Verbindung mit Rock-Star-Firmen und mit Weltkonzernen, deren Software eine markführende Position besetzt. Ich will das mal konkret machen. Wenn ich mich mit Google treffe und über Suchmaschinenprogrammierung rede, dachte ich, dann würden die gar nicht verstehen, wovon ich rede, weil das für die wäre als würden sie sich mit einer Ameise unterhalten. Oder, so die Annahme, mit VMware könnte ich gar nicht über Hypervisor-Programmierung reden, weil die da ja wahrscheinlich auf einem so viel höheren Niveau ein Verständnis aufgebaut haben, dass ein Gespräch mit jemandem wie mir für die keinen Sinn ergeben würde.
Nun hat es sich ergeben, dass ich beruflich Software auf Sicherheitslücken absuche. Ich gehe zu großen Firmen, die zeigen mir ihren Quellcode, und ich zeige ihnen dann, wo sie Dinge falsch machen. Wie viele Menschen in dem Beruf habe ich das Impostor Syndrome, d.h. ich befürchte regelmäßig, dass gleich jemand erkennt, dass ich gar keine Ahnung von der hier gefragten Wissens-Domain habe, und dann entfernt mich die Security aus dem Gebäude.
Einen besonders krassen Fall von Impostor Syndrom hatte ich, als ich das erste Mal bei Microsoft Windows auditiert habe. Die hatten auch keine Ahnung, wie man sowas macht, und wen man da ranlässt, und hatten daher ein vergleichsweise weites Netz geworfen, um potentielle Auditoren zu finden. Ich für meinen Teil hatte so gut wie keine Erfahrung mit Windows. Ich hielt das für einen Irrtum, dass die mich da hin geholt hatten. Und dann geschah das Wunder von Redmond. Ich setze mich hin, gänzlich ohne Domain Knowledge, und fand mehr Bugs als die ganzen Leute mit Domain Knowledge.
Wie sich rausstellt, ist Domain Knowledge überbewertet. Und Microsoft war sich dessen stärker bewusst als ich.
Aber diese Gedankengänge verfolgen mich bei allen Kunden. Was macht Microsofts GUI-Zeug zum Marktführer? Gibt es da irgendwas, was die besonders großartig machen? Wie funktioniert das Memory Management von Windows? Hat der Hypervisor von VMware ESX im Vergleich zu Xen Roswell-Technologie im Einsatz? Was ist eigentlich der Unterschied zwischen Oracle und MySQL? Ist das wirklich so ein immenser Abstand?
Gelegentlich ergibt sich die Gelegenheit, mit einigen wichtigen Leuten mal ein Bierchen trinken zu gehen. Ich nutze sowas konsequent, weil es mein Weltbild enorm erweitert hat über die Jahre.
Einige der gewonnenen Einsichten möchte ich gerne mit euch teilen. Bei allen großen, wichtigen Weltprodukten, bei denen ich eine Einsicht in diesen Aspekt gewinnen konnte, war das anfangs mal ein Hack von drei Leuten. Also wörtlich jetzt. Drei Leute ist die typische Größe, mit der man großartige Produkte bauen kann. Wenn wir nur von einem Aspekt reden, der am Ende die Großartigkeit des Produktes zementiert hat, ist es häufig gar nur einer. Der 32-bit-Support von Windows 95 geht auf einen Typen zurück, der das Manual von Intel auf dem Schreibtisch hatte (das konnte man sich damals für fast lau per Post ordern oder gratis als PDF runterladen), und der die entsprechenden Absätze gelesen hatte, und der sich dachte, hey, das implementiere ich doch mal.
Der schönste Spruch in diese Richtung kam von einem Datenbank-Hersteller. "Wenn wir damals Datenbank-Leute eingestellt hätten, wären die großartig darin gewesen, uns zu sagen, warum soundso nicht geht. Daher haben wir Nicht-Datenbank-Leute eingestellt, und die haben dann einen Weg gefunden."
In meiner Erfahrung ist der größte Motivator in der Softwareentwicklung die Gewissheit, dass etwas substantiell besser geht. Eine schöne Anekdote dazu hörte ich vor einer Weile. Da ging es darum, dass ein Software-Hersteller mit einer Uni zusammenarbeitete, und die hatten eine coole Idee und die auch umgesetzt im Rahmen einer Forschungsarbeit, und die blies alles aus dem Wasser, was es in dem Feld gegeben hatte. Der Hersteller hat daraufhin sein eigenes Team an einen Tisch geholt, wieder mal die fast sprichwörtlichen drei wirklich fitten Leute, und hat denen gesagt: implementiert das mal. Ihr habt das nicht erfunden, daher erwarten wir nicht, dass euer Prototyp diese Uni-Lösung outperformed, aber zumindest bis auf 50% solltet ihr rankommen. Die drei fitten Leute sind losgezogen und haben einen Prototypen gehackt, und hatten offensichtlich eine völlig falsche Vorstellung davon, welche Baseline sie erreichen müssen. Als sie ein paar Wochen/Monate gehackt hatten, und ihren Prototypen zeigten, und jemand den gegen das Uni-Ding auf gleicher Hardware benchmarkte, war der (edit: ihr Prototyp) nicht etwa 50% langsamer (edit: als die Uni-Software) sondern über 50% schneller.
Niemand geht los, um langsame Software zu schreiben. Aber auf dem Weg brechen viele Leute ab, weil ihnen gesagt wird, die Dinge seien "schnell genug".
Neulich scrollte eine lustige Gegenüberstellung an mir vorbei. Da hat sich einer der Väter von Extreme Programming vorgenommen, jetzt mal einen Sudoku-Löser zu programmieren. Der hat mehrere Blogposts dazu gemacht. Er hatte ein festes Dogma, wie man an sowas herangeht, aber offensichtlich keine Vorstellung, wie man diese Art Problem löst. In den Blogeinträgen beschreibt er jeweils, wie er Tests programmiert und ein neues Darstellungsformat ausprobiert. Am Ende scheitert er. Die Gegenüberstellung ist ein relativ bekannter Google-Ingenieur. Der hat auch ein Blogposting geschrieben. "Ich schreibe jetzt mal einen Sudoku-Löser". Dann hat er sich hingesetzt, beschrieben, wie man sowas macht, und einen Löser geschrieben. Ein Blogpost.
Es ist einfach, nach sowas über Extreme Programming zu lachen. Aber ich glaube, dass wir über noch ganz andere Dinge lachen sollten. Ich glaube, dass wir einige sehr fundamentale Dinge in Sachen Softwareentwicklung schlicht noch nicht verstanden haben. Nicht nur das: Die Leute setzen systematisch Scheuklappen auf, um zu verhindern, sich damit auseinandersetzen zu müssen.
Ich habe einmal einen Code Audit einer Webplattform gemacht. Normalerweise drücken sich Auditoren um sowas, weil man befürchten muss, dass sowas in PHP oder — schlimmer noch — Perl geschrieben ist. Das sind klassische Write-Only-Programmiersprachen. Da kann nach einer Woche auch der Typ, der es geschrieben hat, nicht mehr sagen, was dieser Code hier eigentlich tun sollte. In diesem Fall war es Perl. Wir machten drei Kreuze und fingen an. Und jetzt der Schocker: Das war wunderbar lesbarer Perl-Code. Kommentiert. Minimal. Die Firma hatte beschlossen, dass das Verbessern von bestehendem Code genau so wertvoll ist wie das Schreiben neuen Codes. Eher noch wertvoller. Wenn ein Mitarbeiter inzwischen dazugelernt hat, dass man Problem X besser so löst als wie wir das damals gemacht haben, dann geht er hin und löst es so. Unlesbarer Code wurde konsequent nicht gedulded. Fiese Konstrukte wie eval waren verpönt und nur unter strikten Ausnahmeregelungen erlaubt. Dieser Perl-Code war besser auditierbar als der durchschnittliche C++-Code. Lektion: Es liegt nicht an der Programmiersprache. Es liegt daran, dass die Firma der Lesbarkeit von Code einen Wert zuweist.
Der oben erwähnte "war am Ende 50% schneller"-Code hat dem Management so gut gefallen, dass sie gesagt haben: Geil, shippen wir. Das war cooler Rockstar-Code, aber das war kein Produkt. Für eine Firma dieser Größe und Erfahrung war es kein Problem, aus dem Codehaufen ein Produkt zu machen, das technisch den Anforderungen genügte.
Aber wenn ich da jetzt als Auditor hinkomme und sage: Schaut mal hier, das ist eine schlechte Idee, ändert das mal lieber! Dann sagen die mir: Können wir nicht; Eine Änderung hier könnte unvorhergesehene Auswirkungen über das ganze Produkt haben. Das Risiko können wir nicht eingehen.
In fast allen Großkonzernen, in denen ich bisher Einblicke in diesen Aspekt gewinnen konnte, gibt es große Codemassen, deren Wartbarkeit Nahe Null ist. Weil die Firmen es nicht geschafft haben, ihre Mitarbeiter dazu zu motivieren, alten und schlechten Code Schritt für Schritt besser zu machen. Stattdessen gibt es üblicherweise eine Kultur des Drucks, neue Innovationen zu programmieren.
Es ist schockierend, wie wenige Jahre ins Land streichen mussten, bis aus einem innovativen Stück Rockstarcode ein unwartbarer Haufen Legacy geworden ist.
Zusammenfassung: Firmen überbewerten "wir müssen das ans Laufen bringen" und unterbewerten "wir müssen dafür sorgen, dass das auch wartbar ist". Es werden immense Geldmengen dafür verbrannt und Mitarbeiterberge damit verschlissen, ungepflegten alten Code weiter ungepflegt zu halten, aber noch Dinge ranzupflanschen. Ich glaube, wenn wir hier das Anreizsystem umdrehen könnten, könnten wir auf einen Schlag die Softwareentwicklung umkrempeln und Deutschland zum Weltmarktführer machen.
(etwas älteres Bild)