Bei unseren Softwareprojekten kommen oft die gleichen Fragen unserer Kundinnen und Kunden. Brauchen wir wirklich ein Framework ? Sollten wir das nicht besser alles selbst entwickeln? Brauchen wir die Abhängigkeiten zu externen Bibliotheken? Die Antworten, kurz zusammengefasst: Ja. Nein. Und: Kommt drauf an.

Was sind die Ängste?

Aber woher kommt diese Skepsis vor Bibliotheken, Frameworks und externen Abhängigkeiten? Oft von Angst vor Abhängigkeit und einem Kontrollverlust. Diese Gründe sollte man in der Produktentwicklung natürlich ernstnehmen. Was passiert, wenn ein Framework sich in eine andere Richtung entwickelt als das eigene Produkt? Wenn die Entwicklung einer Bibliothek eingestellt wird? Oder wenn eine Sicherheitslücke darin auftaucht?

Warum gibt es Frameworks und Softwarebibliotheken?

Aber betrachten wir es aus einer anderen Perspektive. Warum gibt es Frameworks und Softwarebibliotheken? Aus einem ähnlichen Grund, warum es Schrauben, Säge und Holzlatten im Baumarkt gibt: Man will für einen Gartenzaun eben nicht selbst einen Baum fällen.

Durch vorgefertigte Teile – Softwarebibliotheken – müssen wir das Rad nicht neu erfinden. Stattdessen kommen wir mit ihnen schneller, sicherer und effizienter ans Ziel.

Was sind dann die Probleme mit externen Abhängigkeiten?

Probleme entstehen, wenn

• die passenden Holzlatten für die zweite Hälfte des Gartenzauns nicht mehr verfügbar sind,
• der gekaufte Schaubenzieher nicht mehr zu den neuen Schrauben passt
• oder die Säge wegen einem Produktionsfehler erhöhte Verletzungsgefahr aufweist und zurückgerufen wird.

Aber reicht das Wissen um diese potentiellen Probleme, um selbst die Bäume zu fällen und daraus passende Holzlatten zu fertigen und selbst in die Schrauben- und Sägeproduktion einzusteigen? Vermutlich nicht. Außerdem: Wie wahrscheinlich sind die Probleme überhaupt?

Sind diese Probleme wirklich wahrscheinlich?

Bleiben wir beim Gartenzaun-Szenario: Solange der Absatz passt, wird das Herstellerunternehmen auch passende Holzlatten produzieren. Ein Auslaufen des Produkts ist zwar möglich, aber üblicherweise wird es Lagerbestände der alten Holzlatten geben oder eine Übergangszeit.

Das Schraubenunternehmen wird Interesse haben, die Kompatibilität zu bestehendem Werkzeug aufrecht zu erhalten. Selbst bei einer neuen Schraubenversion werden die alten noch eine gewisse Zeit weiter produziert werden. Zumindest bis genügend Leute zum neuen System gewechselt sind.

Und im Fall der Säge können wir davon ausgehen, dass bei einem Produktionsfehler ein Rückruf stattfindet. Die fehlerhafte Säge wird ziemlich sicher kostenfrei ausgetauscht werden.

Warum nicht alles selbst entwickeln?

Auch bei Softwarebibliotheken kommt so etwas vor. Also warum nicht alles selbst machen? Dann hat man diese Probleme doch alle nicht mehr. Oder? Stimmt, aber dafür hat man ganz andere.

Will ich – komplett allein – einen Gartenzaun bauen, muss ich selbst einen Baum fällen. Den muss ich dann für passende Holzlatten auch selbst verarbeiten. Das sind viele Arbeitsschritte, mit denen ich nicht vertraut bin. Ich habe ja auch mehr Ahnung von Zäunen, als vom Aufbereiten von Bäumen. Darunter leiden Effizienz, Qualität und Kosten.

Die Strategie “Do it yourself” – oder “re-invent the wheel” – ist so nicht konkurrenzfähig. Ich mache das Gleiche wie spezialisierte Unternehmen. Nur teurer und schlechter.

Was gibt es bei externen Abhängigkeiten zu beachten?

Alles selbst zu machen, ist keine Lösung. Aber wie vermeide ich die realen Risiken von externen Frameworks und Bibliotheken? Wie finde ich jene, die mir keine Probleme machen werden? Wir haben ein paar Punkte definiert, die dabei helfen:

Verbreitung

Wie viele andere Projekte setzen meine externe Komponente noch ein? Oft verwendete Schrauben werden wahrscheinlich weiter produziert und bei Weiterentwicklungen ist ein Blick auf die Kompatibilität wahrscheinlicher. Bei einer exotischen Schraubenvariante ist das unwahrscheinlicher.

Hintergründe

Wer hat die Säge entwickelt? Eine einzelne Person oder ein großes Unternehmen? Ist die Säge ein Hauptprodukt oder nur ein zufällig entstandenes Sideproject? Ist die Herstellung der Säge mit einem Patent geschützt bzw. ein Betriebsgeheimnis oder sind die Pläne frei verfügbar, also “Open Source”?

Geschichte

Wie lange gibt es diese Holzlatten schon? Sind sie bewährt oder müssen die erste Kinderkrankheiten noch entdeckt werden? Wie haben die Produktpflege und die Fehlerbereinigung bisher funktioniert? Wie schnell wird auf gemeldete Fehler reagiert? Wie viele offene Fehler und Probleme gibt es damit?

Funktionen

Gibt es die Latten im Baumarkt nur in drei Längen, wenn ich genau etwas dazwischen brauche, dann brauche ich maßgefertigte. Auch Frameworks und Bibliotheken müssen zum Einsatzfall passen. Bei unpassenden Frameworks muss man sehr viel “außen herum” programmieren, bis es passt. Also das Fundamt des Gartenzauns erhöhen, weil es keine längeren Holzlatten gibt. Manchmal ist dieses “Herumbauen” aufwendiger und fehleranfälliger als ein Wechsel, oder sogar eine Eigenentwicklung.

Diese Fragen helfen bei einer Auswahl. Die letzte Entscheidung hängt aber immer von den eigenen Bedingungen ab. Ein Softwaresystem im Bankwesen hat andere Entscheidungskriterien für externe Bibliotheken als Netflix.

Ist es immer falsch selbst etwas zu entwickeln?

Gibt es passende und etablierte Lösungen, sollte man sie einsetzen. Natürlich gibt es Ausnahmen für diese Regel, aber die sind rar gesät. Man spart Zeit, Geld und kann sich auf der Lösung des eigenen Kernproblems widmen. Dafür gibt es ja vielleicht noch gar keine Bibliothek.

Gibt es externe Abhängigkeiten, kann man die Austauschbarkeit von Bibliotheken schon im vorhinein durch eine vorausschauende System- und Softwarearchitektur berücksichtigen und erleichtern. Von Facade-Design-Pattern bis hin zu Microservices und Microfrontends gibt es für jedes Softwaresystem passende Architekturmuster.

Individualentwicklungen sind die richtige Entscheidung, wenn sie aus gutem Grund erfolgen. Zum Beispiel wenn bestehende Bibliotheken ein Problem nur unzureichend lösen oder sie den eigenen Anforderungen hinsichtlich Sicherheit oder Performance nicht genügen.

Fazit

Keine Angst vor externen Abhängigkeiten! Definierte Kriterien und Richtlinien helfen bei der Auswahl externer Abhängigkeiten. Gleiches gilt für Berichte anderer, die schon Erfahrung damit haben und auf Vorteile und Fallstricke hinweisen können. Die Auswahl externer Abhängigkeiten und passender Architektur ist die Grundlage für ein effizient wartbares, leistungsfähiges und sicheres Softwaresystem. Egal ob Website, Web-App, mobile App oder Serversystem.

Ihr braucht Hilfe bei der Wahl des richtigen Frameworks oder Bibliothek?

Get in touch