Mach es nicht selbst!

In der Regel wird mit Softwareentwicklung ein konkretes Ziel angestrebt. Aber auf dem Weg zu diesem Ziel werden immer wieder Bibliotheken, Frameworks, Tools und Protokolle neu erfunden, statt auf Existierendes aufzubauen. Dieses Neuerfinden erscheint anfangs vielleicht als Abkürzung, Vereinfachung oder Verbesserung, aber langfristig ist es oft der Weg in die Hölle!

Die wenigsten Probleme sind so außergewöhnlich, dass es noch keine gute Lösung dafür geben würde. Ich habe schon erlebt, dass ein Logging Framework, ein Event Bus, Futures oder sogar ein komplettes ORM-Framework in der Art von Hibernate selbst geschrieben wurden. Bestenfalls waren diese Lösungen Zeitverschwendung. Sie waren etablierten Technologien unterlegen und wurden zum Problem.

Warum werden solche Dinge dann trotzdem immer wieder selbst entwickelt? Der Hauptgrund ist eine ablehnende Haltung gegenüber der Aneignung externen Wissens, was häufig auf schlechte Erfahrungen zurückzuführen ist. Das Phänomen ist auch als Not-invented-here-Syndrom bekannt. Ein anderer wichtiger Grund ist Unkenntnis. Natürlich gibt es auch das edle Motiv, alles besser machen zu wollen – nur leider gelingt das selten.

Warum nicht selbst entwickeln?

Mit der Selbsterstellung ist oft ein großer Aufwand verbunden, der zu Beginn tendenziell unterschätzt wird. Um die Eigenentwicklung dauerhaft leistungsfähig oder überhaupt verwendbar zu halten, muss zudem mit anhaltendem Wartungsaufwand gerechnet werden. Software ist gewissermaßen wie ein Kind, für das man ab der Geburt verantwortlich ist und lange bleibt. Die Arbeitsleistung, die in die Entwicklung von Basistechnologien gesteckt wird, fehlt zudem für die eigentlichen Aufgaben.

An Eigenentwicklungen sind oft nur sehr wenige Entwickler beteiligt. Als Folge davon gibt es sehr wenig Kritik und Anregungen von außen. Im ungünstigen Fall bleiben sogar fundamentale Schwächen unentdeckt.

Die Abhängigkeit von einzelnen Wissensträgern ist ein Problem, wenn das Wissen mit seinen Trägern verschwindet. Mit einer gut dokumentierten Software wäre das kein Problem. Prinzipiell könnte natürlich auch die selbst entwickelte Software gut dokumentiert werden, praktisch ist sie das nur leider selten. Durch den kleinen Anwenderkreis fällt oft nicht einmal auf, wie schlecht die eventuell vorhandene Dokumentation ist.

Neue Kollegen haben es schwer, denn sie werden mit einem Eigengewächs zuvor kaum in Berührung gekommen sein. Das heißt, dass sie sich in eine so gut wie unbekannte, wahrscheinlich unzureichend dokumentierte und vielleicht auch noch eigenartig aufgebaute Software einarbeiten müssen. Eine gängige Technologie würden neue Kollegen schon eher kennen. Und wenn das nicht der Fall ist, würde ihnen zumindest die in der Regel ordentliche Dokumentation helfen.

Entwicklerkapazität fehlt, sobald direkte Kundenwünsche umgesetzt werden müssen oder ein lukrativer Auftrag winkt, denn dann werden sofort Entwickler von der Arbeit an der eigenen Lösung abgezogen. Wegen der geringen Priorität, wird auch wenig Aufwand in die interne und externe Qualität gesteckt.

Fehlende Kontinuität bei den Mitarbeitern folgt aus dem vorigen Punkt. Durch wechselnde Mitarbeiter geht Wissen verloren und es ändert sich vielleicht auch der Entwicklungsstil und Fokus einer Softwarelösung. Ein besonders schwerer Fall von fehlender Kontinuität ist das gemeine “Praktikanten- oder Studentenprojekt”.

Viele Qualitätsmängel bleiben unentdeckt, wenn die selbst erfundene Software nur im kleinen Rahmen eingesetzt wird. Grenzfälle werden durch die wenigen Anwendungsfälle keinem Praxistest unterzogen oder Spitzenlasten treten vielleicht nie auf. Das kann eine ganze Weile gut gehen, aber das Risiko ist deutlich höher, als wenn man auf eine bewährte, vielfach eingesetzte Lösung zurückgreift. Besonders kritisch kann eine falsche Architektur werden, denn die lässt sich nachträglich nur mit sehr viel Aufwand ändern. Selbst für einen Wechsel auf bewährte Technologien ist es dann in der Regel zu spät.

Instabile Schnittstellen sind eine Begleiterscheinung mangelnder Reife, was wiederum weitere Anpassungen nach sich zieht. Solche Änderungen sind bei neuer Software normal, weil man auf dem Weg noch jede Menge lernt. Stattdessen mit schlechten Schnittstellen zu leben, ist auch keine Lösung. Diese Irrwege sind die Entwickler eines ausgereiften Frameworks bereits gegangen, sodass man direkt zum Ziel gehen darf.

Wissen fehlt in der Regel, wenn Software für ein schwieriges oder komplexes Themengebiet entwickelt werden soll und die Entwickler nicht gerade Experten auf diesem Gebiet sind. Zumindest anfänglich wird die eigene Lösung deshalb viele Fehler und Probleme enthalten, die anderswo längst gelöst wurden. Experte zu werden ist ein langer, steiniger Weg. Bewährte Bibliotheken und Frameworks enthalten dagegen jede Menge Wissen und Praxiserfahrung.

Da die Ressourcen begrenzt sind, werden oft nur die allerwichtigsten Anwendungsfälle abgedeckt. Mit der Zeit zeigt sich dann aber, dass man eigentlich viel mehr Funktionalitäten bräuchte und dann steht man vor der Wahl, die bereits investierte Zeit abzuschreiben und auf eine marktübliche Lösung zu wechseln oder noch viel mehr Geld und Zeit in die Weiterentwicklung zu investieren.

Für die eigene Lösung gibt es keine Werkzeugunterstützung. Während etablierte Frameworks und Bibliotheken sehr gut durch Entwicklungsumgebungen unterstützt werden, ist man mit seiner eigenen Lösung auf sich gestellt.

Verhütungsmittel

Wenn man sich auf dem Laufenden hält und Fachpresse, Blogs oder Konferenzen verfolgt, bekommt man einen guten Überblick und reduziert die Gefahr, dass man aus Unkenntnis etwas neu erfindet.

Wichtige Themen zu vertiefen und zu üben hilft dabei, die Technologien wirklich beurteilen und einsetzen zu können.

Immer wieder neue Technologien zu erlernen, fördert die Bereitschaft, sie auch einzusetzen und beugt Verkrustung vor.

Unternehmen sollten fest eine gewisse Zeit und ein Budget für Weiterbildung einplanen, denn sonst veraltet das Wissen, wodurch Produktivität und Qualität im Vergleich zum Markt immer weiter absinken.

In vielen Unternehmen gibt es eine Hamsterrad-Kultur in der alle immer furchtbar beschäftigt wirken (müssen). Zeit, in Ruhe ein Buch zu einem Thema zu lesen, gibt es nicht. Stattdessen wird der Code in die Tastatur gekloppt, als gäbe es kein Morgen mehr. Da werden Mannmonate oder -jahre verschwendet, unzählige Fehler, Performance-Probleme oder Sicherheitslücken in Kauf genommen, weil niemand Zeit hatte, die Dokumentation zu lesen!

Eigenentwicklungen sollten immer begründet werden. Dazu gehört insbesondere eine Recherche, welche bestehenden Lösungen es gibt und eine detaillierte Begründung, warum sie nicht geeignet sind und es wirtschaftlicher ist, selbst bei null anzufangen. Wenn es keine gute Begründung gibt, ist es wahrscheinlich auch keine gute Idee.

Bevor man selbst anfängt, ein Framework oder eine Bibliothek zu schreiben, ist es in jedem Fall gut, die existierenden Lösungen so gut zu kennen, dass man ihre Entwurfsmuster, ihre Stärken und Schwächen kennt, denn nur dann ist man in der Lage, gezielt etwas Besseres zu entwickeln – andernfalls wäre das Zufall.

Reviews helfen, Eigenbrötlerei zu reduzieren. Wenn ein Entwickler zu lange alleine vor sich hin bastelt, merkt er vielleicht gar nicht mehr, dass nur noch er selbst die Lösung verstehen kann und erfährt unter Umständen nie, dass es eigentlich schon fertige Lösungen geben würde. Als milde Form des Reviews ist auch Paarprogrammierung geeignet.

Wenn schon Eigenentwicklung …

Wenn es nun trotzdem unbedingt eine Eigenentwicklung sein muss, dann sollte sichergestellt sein, dass

• die Entwicklung ein klares Ziel und klare Grenzen hat
• dauerhaft genügend Entwicklerkapazität bereitsteht, auch bei Engpässen
• genug Zeit für Qualitätssicherung und Refactorings vorhanden ist
• erstklassige Dokumentationen geschrieben und aktuell gehalten wird

Sofern es möglich ist, wäre es für die Qualität auch förderlich, ein Open-Source-Projekt aus der selbst entwickelten Software zu machen. Denn erstens gibt es da Rückmeldungen von außen und zweitens motiviert die öffentliche Präsentation, ordentliche Arbeit abzuliefern.

Falls es sich bei der Neuerfindung um ein Lehrprojekt handelt, sollte es auch nur als solches verwendet werden und nicht ernsthaft im Unternehmen eingesetzt werden. Andernfalls würde die Software ein Eigenleben und eine Dauerhaftigkeit entwickeln, für die sie nie ausgelegt war.

Zusammenfassung

In den wenigsten Fällen ist es sinnvoll, eine grundlegende Technologie selbst zu entwickeln. Meistens verschwendet man damit Zeit und Geld für eine qualitativ schlechtere Lösung, die sogar existenzbedrohend werden kann. Verfügbare Technologien zu erlernen, erfordert zwar mitunter einen erheblichen Aufwand, aber langfristig zahlt sich der gegenüber einer Eigenentwicklung aus.

Nutze existierende Lösungen, in denen viele Fehler schon behoben sind, die du noch machen würdest. Profitiere von all der Erfahrung, die darin gesammelt ist. Stehe auf den Schultern von Riesen und mach es nicht selbst!

Weitere Information

• Is reinventing the wheel really all that bad? (stackexchange.com Software Engineering)