Interview mit Carlo Pescio

Schöner Code ist nicht unbedingt guter Code

Gabriela Motroc
Carlo Pescio

Seit dreißig Jahren schon bestimmt Software das Leben des Programmierers Carlo Pescio. Jetzt hat er ein Paper mit dem Titel „Decisions, Assumptions, and Overfitting or why most „clever“ code ain’t so clever after all” veröffentlicht. Darin behauptet er, dass cleverer Code eigentlich alles andere als guter Code ist, sondern lediglich äußerst fragil. Wir haben ihn gefragt, warum cleverer Code unter dem Druck der Veränderungen bricht und was getan werden kann, um dies zu verhindern.

In einem kürzlich veröffentlichten Paper hat Carlo Pescio darauf aufmerksam gemacht, dass es eine regelrechte Sinnflut von angeblich cleverem Code gibt, die permanent von den Gurus auf die Hipster auf die unbedarften Leser herunterregnet. Heutzutage tritt diese Art cleveren Codes vor allem in Form von Snippets für das Funktionale Programmieren auf. Leider denken die Leute, dass dieser Stil angeblich cleveren Codens repräsentativ ist für gutes Funktionales Programmieren. Doch genau dieser Stil führt zu fragilem Code. Dieser ist nicht in der Lage, eine noch so kleine Änderungen der Anforderungen anzunehmen, ohne dass man größere Änderungen in der Hauptstruktur und -strategie vornehmen muss. Pescios Meinung nach müsse das aber nicht sein, aber dafür müsse jemand den Bösewicht spielen und zeigen, dass es nicht clever ist, sondern fragil.

JAXenter: In deinem Paper behauptest Du, dass cleverer Code in Wahrheit ziemlich fragil ist. Wie kommt das?

Carlo Pescio: Wir Menschen lieben Symmetrien und Regelmäßigkeiten. Wir finden sie schön und elegant. Deshalb schneiden wir harte Edelsteine in symmetrische Formen; eben weil wir uns – visuell und intellektuell – von diesen Formen angezogen fühlen.

„Cleverer“ Code nutzt diese wahrgenommenen Regelmäßigkeiten in den jeweiligen Problembereichen aus und antwortet mit streng symmetrischen Lösungen, die oft auf mathematisch inspiriertem Sprach- oder Library-Support basieren. Regelmäßigkeiten erlauben Minimalismus und wir nehmen die symmetrische Form des finalen Artefakts als schön wahr. Wir tendieren dazu, minimalistisch und schön als clever anzusehen. Dumm nur, dass die echte Welt weder regelmäßig noch symmetrisch ist. Sie wird ständig mit Grenzfällen, wahllosem Verhalten, absurden Regulierungen, die man doch befolgen muss, und Hardwarefehlern, die man auf Softwareebene reparieren muss, aufwarten. Code, der Unregelmäßigkeiten nicht erlaubt, mag vielleicht schön anzusehen und clever sein, aber genau wie ein Brillant wird er nur schwerlich seine Form ändern. Hochgradig regulierte Strukturen lassen sich nicht anpassen und weiterentwickeln, ohne dass ihre empfindliche Balance gestört wird. Der Minimalismus bietet keinen Raum für Wachstum und Anpassungsfähigkeit. Man muss jedes Mal die Lösung von Grund auf überdenken, anstatt sie einfach weiterzuentwickeln sobald es nötig wird. Wenn man nur Puzzles lösen und seinen Fähigkeiten beweisen will, ist das in Ordnung, aber nicht wenn man Teil eines Teams ist und an echtem Code arbeitet.

JAXenter: Warum ist es so wichtig Veränderung zu erleichtern?

Hochwertige Software wird immer von einer Sphäre der Ungewissheit umgeben sein.

Carlo Pescio: Hochwertige Software wird immer von einer Sphäre der Ungewissheit umgeben sein. Ungewissheit mag als technologische Herausforderung, als sich verändernde Umwelt oder als Fluktuation von Marktchancen auftreten, aber sie ist immer da. Wenn es keine Ungewissheit gibt, besteht eine hohe Wahrscheinlichkeit, dass das Problem bereits gelöst wurde und zu einem Allerweltsprodukt geworden ist.

Man kann auf unterschiedliche Weise mit der Ungewissheit umgehen. Manche Veränderungen können grob geplant werden – natürlich muss man dafür wissen, was die genaue Veränderung ist, mit der man konfrontiert werden wird. In dem Fall hat man aber ein Wachstumsmodell für zumindest einen Teil des Problems oder des Produkts parat und kann dann entsprechend dafür entwickeln. Die meisten Veränderungen können jedoch nicht vorhergesagt werden; es ist also unvernünftig, alles auf zunehmendes Wachstum auszurichten. Allerdings wird der Wandel kommen und manchmal wird ein wichtiger Deal von ihm abhängen. Demnach muss Code in der Lage sein, Veränderungen anstandslos zu akzeptieren; insbesondere die fiesen, irregulären Veränderungen aus der echten Welt. In meinem Paper habe ich auf Richard Gabriels Idee bewohnbarer Software (Habitable Software) hingewiesen und empfehle jedem wärmstens, seinen Aufsatz zu diesem Thema zu lesen.

JAXenter: Du sagst außerdem, dass cleverer Code unter der Last der Veränderung brechen kann. Wie können wir sicherstellen, dass das nicht passiert? 

Carlo Pescio: Die ehrliche Antwort lautet, dass wir keine wirkliche Methode besitzen, um sicherzustellen, dass der Code aufgrund von Veränderungen nicht zusammenbricht. Wie viele Real World Issues wurde das Problem von der Informatik lange ignoriert und lediglich mit „Prinzipien“ in der Softwareentwicklung überbrückt. Immerhin verfügen wir über einige pragmatische Ideen, worauf wir hinarbeiten und was wir vermeiden sollten. Um nur zwei Punkte aus meinem Paper zu wiederholen:

  • Wie müssen uns der Annahmen bewusst sein, die wir machen, und wie tiefgreifend diese sein werden. Wir müssen sichergehen, dass wir die Annahmen lokal außer Kraft setzen können, wenn die fiese echte Welt es erfordert.
  • Wir sollten uns von Strukturen fernhalten, die grundsätzlich unfähig sind, mit Unregelmäßigkeiten umzugehen.

Es gibt natürlich viele weitere Zutaten, die in das Rezept für flexible Software gehören. Davon kreisen viele um Softwareentwicklung. Aber ein gutes Verständnis des Problemgebiets bleibt trotzdem extrem wichtig, da Unregelmäßigkeiten so viel früher erkannt werden können.

Lesen Sie auch: Schreibt weniger Code!

JAXenter: Warum glaubst Du, dass dieses Paper die unbeliebteste Arbeit sein wird, die Du je verfasst hast?

Carlo Pescio: Softwareentwicklung verlangt eine große Hingabe fürs Lernen. Wir investieren viel, um Sprachen, Paradigmen oder Methoden zu lernen. Für viele Leute führt dies zu einer ebenso großen emotionalen Investition. Manche Communities behalten sich einen Sinn für Selbstironie und Verhältnismäßigkeit, andere leider nicht. Manche sind sogar um die Idee herum konstruiert, dass ihr Weg der Überlegene ist. Wenn dann aber Makel in den Konzepten, die diese Communities predigen, entdeckt werden, bleiben die Leute still, weil keiner ins Hornissennest stechen möchte. Wer es doch tut, kann sich ausrechnen, was passiert. Ich hab es trotzdem getan.

JAXenter: Warum ist dein Beispiel ausgerechnet in Haskell geschrieben?

Ich habe mich entschieden, die Diskussion vom Haskell-Code ausgehen zu lassen, weil bei jeder anderen Sprache die Leute gesagt hätten „OK, aber in Haskell…“. Interessanterweise wurde mir vorgeworfen, mir spezifisch Haskell und Funktionales Programmieren (FP) herausgepickt zu haben, obwohl ich überhaupt nichts gegen Haskell selbst gesagt habe und obwohl ich mehrmals darauf hingewiesen habe, dass ich Probleme mit einem spezifischen – wenn auch populären – FP-Stil habe und nicht mit FP als Paradigma. Aber damit hatte ich ohnehin gerechnet.

Code muss in der Lage sein, Veränderungen anstandslos zu akzeptieren; insbesondere die fiesen, irregulären Veränderungen aus der echten Welt.

JAXenter: Welche Schlussfolgerungen hast du nach Analyse des Codes gezogen?

Carlo Pescio: Sogar bei zwanzig Zeilen Code für ein klares, algorithmisches und bestens definiertes Problem hat die hochgradig regulierte Struktur uns nicht vor einem Bug geschützt. Dieselbe Struktur kann nicht lokal angepasst werden, um eine äußerst vernünftige Änderung (ausgehend vom Problemgebiet) ohne komplette Überarbeitung zu ermöglichen. Obwohl sie aus wiederverwendbaren Library-Funktionen zusammengesetzt wurde, hatte das Resultat so gut wie keine intrinsische Flexibilität und bot nur sehr eingeschränkten Raum für Veränderungen.

JAXenter: Hast du Feedback für dein Paper bekommen? Stimmen die Leute deiner Meinung zu?

Carlo Pescio: Auf Twitter war das Feedback meiner Ansicht nach gut. Die Leute haben die Message verstanden. Ich gehe davon aus, dass viele bereits zu ähnlichen Schlussfolgerungen gekommen sind und sich über ein Paper gefreut haben, dass sich nicht gescheut hat, diese auch auszusprechen. Dann allerdings hat jemand das Paper auf Hacker News und Reddit verlinkt. Ich nehme an, mit guten Absichten. Und ja, es gab das erwartete Schlachtfest. Um fair zu sein: viele der Kommentare sind wohl für die Sozialwissenschaften interessanter als für die Informatik. Aber das ist OK. Ich habe das Paper geschrieben, weil es eine kleine Wahrheit war, die ausgesprochen werden sollte. Weil das keiner machen wollte, habe ich es dann halt getan. Wenn nur eine Handvoll Leute es nützlich finden, bin ich schon zufrieden.

Vielen Dank für das Interview!

carlo_pescioCarlo Pescio programmiert seit 38 Jahren, mit verschiedenen Sprachen, Paradigmen und Technologien. Er ist Autor und gelegentlich auch Speaker. Mit der Zeit hat er einige Dinge gelernt, sowohl innerhalb als auch außerhalb der Wissenschaften. Er baut an einer fundierten und hoffentlich nützlichen Theorie zu Software-Design.

Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: