By Wolfgang Keller
Originally written 2020-03-13
Last modified 2023-02-04
Golem veröffentlichte 2018-08-28T09:02+02:00 einen Artikel Entwickler-Charaktere: Ninja oder Zauberer? [visited 2020-03-13T00:33:26Z], in dem auf einen Fragebogen [visited 2020-03-13T00:34:17Z] verlinkt wurde, in welchem auf Basis von 4 Gegensatzpaaren bestimmt wird, welcher von 16 Typen von Softwareentwicklern man ist.
Laut diesem Test bin ich der Typ SAIT: The Author.
Auch wenn ich weiß, dass ein solches Testergebnis mit Vorsicht zu betrachten ist, will ich dennoch begründen, warum dieses Ergebnis zumindest kohärent zu meinem eigenen Empfinden ist.
Zur Erklärung der Dimensionen: Design Types: Dimensions [visited 2020-03-13T01:06:22Z].
Bezeichnung The Author: Es stimmt, dass ich mich bemühe, Code so zu schreiben, wie ich wissenschaftliche Papers schreiben würde — also für den Leser gut nachvollziehbar. Code wird nun einmal im Rahmen des Software-Lebenszyklus' vielfach mehr gelesen als geschrieben.
Update 2023-02-04: Ich maße mir selbstverständlich nicht an, einem solchen selbst auferlegten Standard in der Praxis auch nur im Entferntesten standhalten zu können.
Eigenschaft Simple (in Abgrenzung zu Powerful): Ich denke, sehr viele mächtige, allgemeine Konstrukte haben die Eigenschaft, „leaky“ zu sein. Beispielsweise die „everything is a file“-Abstraktion von UNIX: Festplatten sind Block-Devices, Netzwerkpakete haben eine MTU usw. Daher führen Abstraktionen leicht dazu, dass man die tatsächlichen Möglichkeiten, die das System bietet, gar nicht ausnutzt beziehungsweise ausnutzen kann.
Update 2020-10-21: Auch ist es nach meiner Erfahrung so, dass es schwer vorherzusehen ist, was die zukünftigen Erfordernisse des Systems sein werden; hier „powerful abstractions“ im Code zu benutzen, um für eine solche ungewisse Zukunft gewappnet zu sein, sehe ich daher eher skeptisch.
Update 2023-02-04: Auch ist es aus meiner Erfahrung so, dass sich erst im Laufe des Projektes herauskristallisiert, welches sinnvolle Abstraktionen sind. In der Mathematik war es schließlich auch so, dass man mit dem \(\mathbb{R}^3\) als Abstraktion des physikalischens Raums anfing, von dort über die Zwischenschritte
schließlich bei allgemeinen Abelschen Kategorien landete: ein Prozess, der sich über mehrere Mathematiker=Generationen hinzog.
Das heißt natürlich nicht, dass es nicht sinnvoll ist, solche mächtigen, allgemeinenen Konstrukte in Softwareprojekten einzusetzen. Allerdings sollte man sich aus meiner Sicht klar darüber sein, dass Abstraktionen in Softwareprojekten dazu dienen, Dinge zu vereinfachen und daran gemessen werden sollten, inwieweit sie diesem Zwecke in signifikantem Maße dienen (also Dinge nicht stattdessen unnötig komplizierter machen). Ebenso sollte man sich beim Einsatz solcher Abstraktionen immer fragen, welche „leaky abstractions“ durch diese riskiert werden könnten und welches mögliche Optimierungspotential für Codeoptimierungen auf tieferer Ebene wir riskieren, nun nicht nutzen zu können.
Eigenschaft Abstract (in Abgrenzung zu Concrete): Dies ist, denke ich, ebenso wie „Idealistic“ im nächsten Punkt eine Konsequenz meines Hintergrunds aus der Mathematik, wodurch ich es mag, hinter dem Code auch „höhere Muster“ zu sehen.
Update 2023-02-04: In der oben verlinkten Erklärung der Dimensionen findet man als charakteristisches Merkmal von „Concrete“, dass es bei letzterem ein typisches Merkmal ist, das System nicht in allen Details zu verstehen oder dies nicht einmal zu wollen. Ich halte eine solche Einstellung für gefährlich. Aus meiner Sicht stellt es, wenn so etwas nicht möglich ist (was leider in sehr vielen Softwareprojekten in der Praxis der Fall ist!), ein immanentes und ernstzunehmendes Warnsignal dar, dass in der Komplexität des zu entwickelnden Softwaresystems das, was durch das Team gut beherrschbar ist, deutlich überschritten wurde.
Eigenschaft Idealistic (in Abgrenzung zu Pragmatic): Kurzum: Ich bin Mathematiker und sehe es daher als erstrebenswertes Ziel an, dass der Code auch von „innerer Schönheit“ ist.
Eigenschaft Technologic (in Abgrenzung zu Robust): Ich denke, wir haben den „perfekten“ Weg, Software zu entwickeln, noch nicht gefunden. Unter diesen Umständen ist es wahrscheinlich der sinnvollste Weg, den Code nach dem aktuell besten bekannten Stand der Technik (der sich durchaus in (auch naher) Zukunft ändern kann) zu entwickeln. Aus demselben Grund ist es nicht zwangsweise ein Zeichen von besserer Qualität, mit „etablierteren“ Technologien zu arbeiten, insbesondere wenn sich diese, wie ausgesprochen häufig, nicht aufgrund inhärenter qualitativer Merkmale, sondern aufgrund von Marketing etabliert haben.
Update 2020-10-27: Seitentitel umbenannt.