Keine Angst vor NIH

NIH (Not Invented Here Syndrome) bezeichnet etwas humoristisch die häufig anzutreffende Tendenz von Entwicklern, bestehenden Lösungen nicht zu vertrauen und statt dessen es selbst und „richtig“ zu machen. Oft wird dabei der Aufwand unterschätzt, die die eigene Entwicklung benötigt um den Reifegrad der bestehenden Lösung zu erreichen bzw. die eigene Leistungsfähigkeit wird überschätzt. Da dieses Verhalten oft mit einem gewissen Dunning-Kruger-Effekt einhergeht, ist NIH häufig bei juniorigeren Entwicklern zu finden, die auch mit der Implementierung einer eigenen, grundlegenden, besseren und flexibleren Lösung (Ironie) sich ein Stück weit selbst profilieren wollen. Findet man in einer Software daher Bestandteile, für die es auf den ersten Blick auch schon bestehende Lösungen am Markt gibt, wird das daher gerne als unprofessionell und anfängerhaft belächelt. Ist das Ergebnis des NIH qualitativ unter dem, was schon verfügbar wäre ist diese Kritik sicherlich berechtigt, mal abgesehen von der Frage, ob man jungen Entwicklern nicht eine entsprechende Spielwiese schaffen sollte, denn die Lerneffekte sind sicherlich enorm.

Das Gegenstück zu NIH wird teilweise auf als PFE (Proudly Found Elsewhere) bezeichnet und oft ebenso als stümperhaft belächelt; zu nennen sind hier insbesondere die zahllosen Script-Beispiele für CMS wie WordPress oder Typo3, die von selbsternannten Webentwicklern ohne Sinn und Verstand in die Seite copy-pasted werden, ohne den Code zu verstehen geschweige denn die Konsequenzen zu durchblicken. Es ist sicherlich nicht verkehrt, sich an den vielen Codebeispielen zu bedienen, die einem das Internet bietet, aber Verständnis für das was man da tut sollte doch vorhanden sein.

Um aber wieder auf das NIH zurückzukommen: Es kann durchaus vorkommen, dass die bestehenden Lösungen nicht 100% passen und die Frage im Raum steht, inwieweit hier die Implementierung selbst durchgeführt werden sollte. Und da trennt sich die Spreu vom Weizen, denn allzu oft fallen Entwickler und die verantwortlichen Projektmanager, Architekten und wer auch immer in die Entscheidung eingebunden ist in das Muster zurück, Eigenentwicklungen als unprofessionell abzutun. Hier gilt es eine genaue Abwägung zu treffen, welche Kosten und Risiken mit der Eigenentwicklung verbunden sind versus dem langfristigen Gewinn. Gerade dieser langfristige Gewinn kann aber unerwartet hoch werden, wenn die eigene Implementierung sich besser in das Gesamtkonstrukt einbinden lässt oder das Problem besser löst als die vorhandene Lösung.

Je nach Größe und Umfang der zur Diskussion stehenden Lösung benötigt das Mut von allen Beteiligten; von den Entwicklern, die sich der Herausforderung stellen wollen und von den Projektverantwortlichen, die das Risiko mitgehen müssen und zunächst hohe Entwicklungskosten gegen geringen Gewinn (es gibt ja schon eine ähnliche Lösung) tauschen. Es kann sich aber durchaus auszahlen. Wichtig ist hier das Wissen und die Erfahrung insbesondere der Entwicklung, die die Optionen bewerten muss, und das Vertrauen auf deren Urteil. Wenn diese Faktoren gut zusammenspielen, kann NIH auch eine professionelle und gewinnbringende Entscheidung sein.