Softwareentwicklung
Schönes Essay von Fefe über Softwareentwicklung:
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.
Update: Ich sollte vielleicht noch sagen, dass ich wirklich mit Google über Suchmaschinenprogrammierung geredet habe, und gesehen habe, wie in VMware der Hypervisor funktioniert. Nicht nur habe ich verstanden, wie die das machen, die haben das auch noch so gemacht, wie ich das auch gemacht hätte (bzw. habe; einen Hypervisor habe ich noch nicht programmiert, aber eine Suchmaschine. Stellt sich raus, dass die groben Strukturen, was man so für Datenstrukturen verwendet und so, bei Google und mir die selben waren. Na klar haben die auch noch ein paar Tricks, die ich nicht kannte). Das liegt nicht daran, dass ich ein toller Hecht bin, sondern dass fast alle Lösungen für fast alle Probleme naheliegend sind, wenn man ein bisschen über das Problem nachdenkt. Und dann gibt es jeweils noch Hardware-Einschränkungen, die bestimmen, welche Lösungsansätze überhaupt möglich oder zielführend sind. So viel bleibt da am Ende normalerweise nicht üblich. Ich halte es für ein wichtiges Ziel, dass Anwender den immer noch weit verbreiteten Respekt vor Software abbauen. Wenn man ein Haus hat, und zwei Zimmer, und man möchte gerne in der Mitte die Mauer weghaben und ein großes Zimmer haben, dann prüft man die Statik und dann macht man die Mauer weg. Wenn man anbauen will, baut man halt an. Da ist nichts magisches dran. Bei Software ist das auch so. Wenn Google ein Haus baut, dann brauchen sie dafür auch ein Fundament. Wenn Google ein selbstfahrendes Auto baut, dann hat das auch Räder. Und so sieht das bei Suchalgorithmen halt auch aus.
http://blog.fefe.de/?ts=ab72d7ef
***
Ein Hinweis noch zu Softwareentwicklung. Ich bin da wahrscheinlich voreingenommen, weil ich Software entwickle. Dennoch.
Mein Eindruck ist, dass Softwareentwicklung in der Industrie immer mehr als Randdetail betrachtet wird. Die Werbung prügelt da ja auch immer in die selbe Richtung. „Mit diesem Produkt wird alles NOCH VIEL EINFACHER!“ Da kann man dem Management schon nachsehen, wenn die glauben, das sei alles total einfach. So viele Evolutionssprünge in Richtung „jetzt NOCH EINFACHER!1!!“ wie wir schon gemacht haben. Und es stimmt ja auch. Damals unter DOS hatten wir keinen Speicherschutz und mussten Swapping selber implementieren! Damals unter C, wenn wir da einen Zeiger verlegt haben, dann gab es Speicherkorruption! Damals in den Schützengräben, wenn wir da einen Datenblock freizugeben vergaßen, dann leakte der Speicher!! Kann man sich heute gar nicht mehr vorstellen!1!!
Scherz beiseite: Heutzutage liegt der Fokus bei Leuten, die über die Entwicklung von Software reden, häufig auf Management-Dingen. Sowas wie Extreme Programming. In der Ausbildung (der Hinweis kam gerade per Mail rein, und ich gebe das gerne weiter) wird der Eindruck erweckt, man klickt sich in seinem UML-Tool ein Flowchart zusammen, und dann ist die Software fertig. Das tatsächliche Hinschreiben ist dann ein niederer Akt, den kann man ja auch einer Outsourcing-Firma in Indien überlassen.
Dieser Ansatz ist bei Software genau so falsch wie bei allen anderen Dingen. Ganze Industriezweige haben sich inzwischen dem Management und der Qualitätskontrolle von per Outsourcing hergestellten Produkten verschrieben. Der Westen macht überhaupt nur noch Management und Qualitätskontrolle, die Produkte machen die Billiglohnländer. Bei Software ist das noch nicht so, aber wenn man sich Fachzeitschriften durchliest, könnte man den Eindruck gewinnen.
Ich sehe das so: Der Code ist am Ende das Produkt. Nicht der Plan für den Code. Nicht die Broschüren. Nicht die Meetings. Der Code.
Die Kern-Sorge in der Softwareentwicklung sollte daher auch der Code sein.
Die Maßstäbe sollten wie in anderen Ingenieursdisziplinen auch sein. Elektriker legen Kabel ja auch nicht wild in der Gegend herum. Wenn ihr mal bei einem Auto die Motorhaube aufmacht, dann kommt euch ja auch kein Kabelsalat entgegengequollen. Das ist alles so ausgelegt, dass man es schnell und unkompliziert warten kann. Bei Code sollte man das auch so tun.
Dementsprechend ist Code auch nicht fertig, wenn die Funktionalität da ist. Das ist nur der erste Prototyp. Code ist fertig, wenn niemandem im Team ein Weg einfällt, irgendetwas daran besser zu machen.
Übrigens, nochmal als Nachschlag zu dem anderen Softwareentwicklungs-Artikel. Wenn ihr ein System optimieren wollt, dann empfehle ich, da mit der Frage heranzugehen: Wie kriege ich das mindestens doppelt so schnell? Gar nicht mit Klein-Klein aufhalten. Guckt euch das System an. Legt euch den Gedanken zurecht, dass die Konkurrenz das selbe Problem auf der selben Hardware in der halben Zeit löst, und ihr müsst das jetzt besser als die machen. Die größte Hürde beim Bessermachen ist, dass die Leute sich selbst einreden, das sei schon alles gut genug, oder es sei zu riskant, da jetzt für inkrementelle Verbesserungen den Code anzufassen. Wenn man wirklich was erreichen will, muss man da mental diesen Holzklotz aus dem Weg räumen, der einem sagt, soooo viel besser geht das gar nicht, dass sich jetzt der Aufwand lohnen würde. Zu der Feststellung kann man immer noch kommen. Aber das sollte am Ende der Überlegungen stehen, nicht am Anfang.
