Get in touch
In dieser dreiteiligen Blogartikel-Serie wollen wir Dir Flamingo, das auf Go-basierende, modulare Open Source-Framework von AOE, schrittweise näherbringen. Vielleicht hast Du aus dem ersten Teil über die Programmiersprache Go schon spannende Infos mitnehmen können? Falls nicht, kannst Du ihn jederzeit hier noch einmal nachlesen. Weiter geht es heute in Teil zwei mit interessanten Fakten über Vor- und Nachteile von Development Frameworks im Allgemeinen, bevor im dritten Teil dann Flamingo mit vielen Infos zur Erstellung von maßgeschneiderten, schnellen und flexiblen Webanwendungen im Mittelpunkt steht.
Los geht’s mit Teil 2: Pro/Contra Development Frameworks
Viele sind der Ansicht, dass kein/keine qualifizierte(r) Entwickler:in jemals ein Framework verwenden sollte, um Code zu schreiben, es sei denn, sie/er würde in einer völlig unstrukturierten Umgebung arbeiten. Unabhängig davon, ob die Komplexität der Entwicklungsumgebung wirklich so hoch ist oder dem/der einzelnen Entwickler:in oder dem Team auch nur so vorkommt: Die Notwendigkeit einer strukturierten Vorgehensweise im Dschungel widersprüchlicher Prioritäten, unkontrollierbarer Geschäftsbereiche, Produktgruppen und Systemen von Drittanbietern, macht Development Frameworks bei Entwickler:innen sehr beliebt.
Argumente für und gegen die Verwendung von Development Frameworks sind zahlreich dokumentiert und werden seit Jahrzehnten heftig diskutiert, ohne dass sich ein Konsens abzeichnet. Die häufigsten Begründungen sind:
Pro Development Frameworks
Contra Development Frameworks
Nach Betrachtung des Für und Wider wird schnell klar, warum eine allgemeine Debatte über die Verwendung von Frameworks bereits so lange ohne wirkliches Ergebnis geführt wird. Es gibt tatsächlich nur sehr starke Argumente dafür aber eben auch dagegen. Gerade die Eigenschaften und Merkmale eines Frameworks, die unter bestimmten Umständen klare Vorteile bringen, verursachen unter anderen Umständen fast zwangsläufig Kosten und Nachteile. Jedes Framework ist zwangsläufig eine Reihe von Kompromissen zwischen diesen Vor- und Nachteilen. Die eigentliche Frage ist, ob die Kompromisse, die ein bestimmtes Framework nach sich zieht, einen signifikanten Nutzen für eine Organisation bringen oder eher nicht.
Wenn wir die Tatsache vertiefen, dass ein Framework eine Reihe von Kompromissen zwischen Entwicklungsprioritäten darstellt, stellt sich die Frage: Sind es denn gute oder schlechte Kompromisse? Das lässt sich leider nicht so einfach festlegen, gehen doch die Vorstellungen von einem guten oder schlechten Kompromiss oft weit auseinander. Prioritäten können an dieser Stelle unterschiedlich oder sogar gegensätzlich sein. Dies hat erhebliche Auswirkungen auf die Entscheidungen, die eine Organisation bei dem Einsatz eines Development Frameworks treffen muss. Zum einen geht es um die unterschiedlichen Prioritäten von Entwickler:innen und Management. In einem kleinen, technisch geprägten Unternehmen, in dem die Führungskräfte und das Management vielleicht selbst Entwickler:innen sind, gibt es diesen Gegensatz vielleicht gar nicht. In großen Unternehmen hingegen stehen die Prioritäten des Unternehmens in Bezug auf die Gesamteffizienz der Organisation, verschiedene Kostenarten, langfristige IT-Ressourcen, Nachhaltigkeit, Stabilität und Sicherheit wahrscheinlich in Konflikt mit den Anliegen der einzelnen Entwickler:innen und Produktteams.
Aber wenn die Belange der Entwickler:innen keine Beachtung finden, kann dies dem Management auch Kopfschmerzen bereiten. Es gibt immer eine Marktnachfrage nach qualifizierten Entwickler:innen, und in den meisten Unternehmen ist der Fachkräftemangel auch und vor allem im Bereich Entwicklung ein Fokusthema der Geschäftsführung. Konventionell werden Frameworks hier oft als mächtiger Verbündeter des Unternehmens angeführt, um die Risiken der Fluktuation von Entwickler:innen zu mindern: Die Standardisierung durch Frameworks kann nämlich dazu beitragen, idiosynkratischen, schwer zu fassenden Code zu vermeiden. Dies verringert die Abhängigkeit eines Unternehmens von den ursprünglichen Entwickler:innen einer Anwendung und erleichtert es gleichzeitig neuen Entwickler:innen, sich in die bestehende Codebasis eines Unternehmens einzuarbeiten.
Andererseits ergab eine Umfrage von Stack Overflow aus dem Jahr 2022, dass das Gefühl, bei der Arbeit unproduktiv zu sein, der wichtigste Faktor (45 %) für Unzufriedenheit von Entwickler:innen ist — noch vor dem Gehalt. Die meisten Entwickler:innen sind sehr auf ihre Entwicklungsumgebung und ihre Toolchain bedacht, da sie diese als wichtigen Bestandteil der der eigenen Produktivität betrachten. Die Folgen der Top-Down Auferlegung eines schlecht passenden Frameworks liegen so auf der Hand. Ein anderer wichtiger Faktor im Bezug auf notwendige Kompromisse und unterschiedliche Prioritäten, die in jedem Development-Framework enthalten sind, ist die User:innen-Basis. Die Anforderungen eines Unternehmens mit einem kleinen, autonomen Entwicklungsteam unterscheiden sich erheblich von denen eines CIO, der ein Unternehmensframework für Hunderte/Tausende von Entwickler:innen und unterschiedliche Produktteams in verschiedenen Regionen und Geschäftsbereichen auswählt. Das Framework, das für den einen funktioniert, ist fast zwangsläufig für den anderen nicht geeignet. Unabhängig davon, ob es sich um ein Open Source- oder ein proprietäres Framework handelt, muss es auf die Bedürfnisse einer definierten und relativ homogenen Benutzergruppe ausgerichtet sein, damit die Vorteile die Nachteile deutlich überwiegen.
Die Bedeutung des Feedbacks und die Einbeziehung der Bedürfnisse der End-User:innen ist einer der Hauptgründe für die zunehmende Dominanz von Open Source-Entwicklungssystemen. Die Entwicklung in einer offenen Gemeinschaft basiert auf gemeinschaftlichen Vereinbarungen und produktiven Kompromissen. Wo Gemeinschaften die Benutzer:innen in den Mittelpunkt der Projektleitung und -entwicklung stellen, ist das User-Feedback unmittelbar und inhärent. Open Source-Entwicklungsframeworks sind daher ein Spiegelbild ihrer Gemeinschaften und derer gemeinsamen Prioritäten. In den meisten Leitfäden zur Auswahl eines Open Source-Frameworks wird eine große und vielfältige Projektgemeinschaft als Hauptkriterium aufgeführt. Für kleine Organisationen und einzelne Entwickler:innen, die die Entwicklung in einer bestimmten Programmiersprache beschleunigen wollen, trifft das mit ziemlicher Sicherheit zu, da größere Gemeinschaften stabiler und nachhaltiger sind.
Für User innerhalb eines Unternehmens ist die Größe der Community ebenfalls von Bedeutung für mehr Nachhaltigkeit, aber es gibt noch andere Faktoren, wie die Größe und Stabilität der individuellen Nutzer:innen und der für die Wartung der Systeme verantwortlichen Organisation, die ebenso zur Nachhaltigkeit beitragen und auch noch andere wichtige Rollen spielen. Wie bereits erwähnt, sind die Prioritäten, die die Anwender:innen im Unternehmen an ein Development Framework stellen, oft andere als die von kleineren Organisationen und einzelnen Entwickler:innen. In einer großen, vielfältigen Open Source-Gemeinschaft können die Belange von Unternehmen bisweilen untergehen und schlechte Kompromisse werden so wahrscheinlicher. In vielerlei Hinsicht sind auf Unternehmen ausgerichtete Development Frameworks besser geeignet für Gemeinschaften, die sich darauf konzentrieren, die Entscheidungen und Prioritäten von Unternehmensanwender:innen zu reflektieren, deren Anforderungen und Prioritäten ähnlich sind.
Um dieses Argument zu vertiefen, müssen wir den Kreis zu unserer ursprünglichen Zusammenfassung der Vor- und Nachteile von Frameworks im Allgemeinen schließen. Nehmen wir das Beispiel der standardisierten "Struktur": Mehr Struktur ist in der Regel gleichbedeutend mit einem maßgeblich dogmatischen Rahmen. Für eine kleine Organisation oder eine(n) einzelne(n) Entwickler:in kann dies zu unnötiger Frustration führen. Kreativität und Flexibilität scheinen ohne Not eingeschränkt, ohne dass ein offensichtlicher Nutzen entsteht. Ein Framework, welches in ausgeprägter Form bereits bewährte Verfahren enthält, hat wahrscheinlich auch eine steilere Lernkurve und führt möglicherweise zu mehr unnötigen Abhängigkeiten und Leistungseinbußen bei kleinen Einzelanwendungen.
Betrachten wir nun die Struktur aus dem Blickwinkel des Unternehmens. Für das IT-Management und die Führungskräfte, die versuchen, viele verschiedene Produktentwicklungsteams in eine kohärente Richtung zu lenken, ist eine Form der Konsistenz von Entwicklungspraktiken unerlässlich. Ein Rahmen kann an dieser Stelle ein unschätzbarer Verbündeter sein, wenn es darum geht, den Überblick zu behalten, Stabilität zu gewährleisten, die Abwanderung von Entwickler:innen zu bewältigen (wie oben beschrieben) und, was vielleicht am wichtigsten ist, eine effektivere Zusammenarbeit zwischen den Teams und eine Steigerung der allgemeinen Produktivität zu ermöglichen.
Und aus der Sicht einzelner Entwickler:innen und Teams? Jegliche Frustration darüber, dass Freiheit und Kreativität durch einen vorgegebenen Rahmen eingeschränkt werden, wird wahrscheinlich durch andere Faktoren aufgewogen. Entwickler:innen in Unternehmen müssen in der Regel mehr Drittsysteme integrieren, die sich ohnehin ihrer Kontrolle entziehen - von anderen Entwicklungsteams, externen Diensten und proprietären Anwendungen. In diesem Szenario fungiert ein stärker begrenzter Rahmen als eine Art Diplomat, der die unterschiedlichen Interessen der Teams abgleicht.
Unser Fazit: Die Wahl eines neuen Frameworks ist nicht nur eine komplexe und schwierige strategische Entscheidung, es ist eine ganze Reihe komplexer, schwieriger strategischer Entscheidungen. Denn Funktionen, die ideal auf die Bedürfnisse von Unternehmen zugeschnitten sind, können ein zu großer Kompromiss für kleine Einheiten oder einzelne Nutzer:innen sein und zu einer generellen Ablehnung von Frameworks führen.
Hat Dir unser Blogbeitrag „Pro/Contra Development Frameworks“ gefallen? Dann sei gespannt, wenn es nächste Woche mit dem dritten Teil „Einführung in Flamingo“ weitergeht. Falls Du in der Zwischenzeit Fragen hast, kannst Du Dich gerne über diesen Link an unser AOE-Entwicklungsteam wenden.
