Эффект IKEA и синдром NIH в разработке ПО

• Verzerrung: Wir überschätzen Entscheidungen, die durch eigene Anstrengungen entstanden sind, und gleichzeitig unterschätzen fremde Entwicklungen, besonders wenn sie nicht innerhalb unserer Organisation entstanden sind.
• Was es bricht: Objektive Bewertung der Code‑ und Architekturgüte, Team‑Zusammenarbeit, die Fähigkeit, aus fremden Erfahrungen zu lernen, fundierte technische Entscheidungen zu treffen.
• Evidenzlevel: L2 — 4 Schlüsselstudien. Der IKEA‑Effekt ist in Laboreinstellungen bestätigt (S001, S003), das NIH‑Syndrom in der Softwareentwicklung ist in Praxis‑Cases und organisationsbezogenen Studien dokumentiert.
• In 30 Sekunden erkennen: Das Team lehnt fertige Lösungen ohne Analyse ab, besteht darauf, bestehenden Code neu zu schreiben, verteidigt eigene Lösungen emotional statt argumentativ.

Warum verlieben wir uns in eigenen Code und ignorieren fremde Lösungen?

IKEA‑Effekt — ein psychologisches Phänomen, bei dem wir Objekten, in deren Erstellung wir eigene Arbeit investiert haben, einen hohen Wert beimessen (S001). Im Kontext der Softwareentwicklung bedeutet das, dass Entwickler und Teams die Qualität von selbst geschriebenem Code, Architektur oder Frameworks überschätzen, selbst wenn objektiv bessere Alternativen existieren. Je mehr Zeit und Aufwand in die Entwicklung investiert wurde, desto höher ist die subjektive Bewertung ihres Wertes.

NIH‑Syndrom (Not Invented Here — „nicht hier erfunden“) — ein organisatorisches Phänomen, bei dem Unternehmen und Teams externe Lösungen, Bibliotheken oder Ansätze ablehnen und stattdessen alles von Grund auf neu entwickeln. Es geht nicht nur um Misstrauen gegenüber fremdem Code, sondern um aktive Widerstände gegen die Einführung fertiger Lösungen, häufig begleitet von der Überzeugung, dass interne Entwicklungen immer besser sind. Das NIH‑Syndrom verstärkt sich, wenn die Organisation eine starke Ingenieurskultur hat und stolz auf ihre eigenen Technologien ist.

Diese beiden Phänomene sind eng verknüpft: Der IKEA‑Effekt erzeugt emotionale Bindung an eigene Lösungen, und das NIH‑Syndrom wandelt diese Bindung in organisatorische Politik um. Gemeinsam führen sie dazu, dass Teams Monate damit verbringen, Funktionalitäten zu entwickeln, die bereits in bewährten Open‑Source‑Projekten existieren, oder sich weigern, sich mit den besten auf dem Markt verfügbaren Services zu integrieren.

In der Softwareentwicklung ist diese Kombination besonders gefährlich. Sie erstarrt den Technologiestack, erhöht die technische Schuld, lenkt Ressourcen von Innovationen ab und erzeugt die Illusion von Qualitätskontrolle. Teams, die vom NIH‑Syndrom betroffen sind, überschätzen häufig ihre Fähigkeiten — ein Phänomen, das dem Dunning‑Kruger‑Effekt ähnelt, bei dem mangelnde Erfahrung die objektive Einschätzung der Aufgabenkomplexität behindert.

Die Überwindung dieser Verzerrung erfordert ein bewusstes Trennen zwischen emotionalem Wert (ich habe das erstellt) und praktischem Wert (das löst die Aufgabe am besten). Gesunde Teams führen regelmäßig Audits bestehender Lösungen durch, etablieren klare Kriterien für die Auswahl zwischen „eigenem“ und „fremdem“ Code und fördern die Bereitschaft, von anderen Entwicklern zu lernen.

Schlüsselunterschied

Der IKEA‑Effekt ist eine persönliche Verzerrung der Wertwahrnehmung. Das NIH‑Syndrom ist ein organisatorisches Verhalten, das auch ohne den IKEA‑Effekt existieren kann, wenn im Unternehmen grundsätzlich externen Lösungen nicht vertraut wird.

Kognitive Architektur des Besitzes: Wie Arbeit die Wahrnehmung umschreibt

Psychologische Besitzzuweisung durch Investition von Aufwand

Wenn Entwickler*innen oder ein Team erhebliche Anstrengungen in die Erstellung einer Lösung investieren, bewertet das Gehirn deren Wert automatisch neu (S001, S003). Dieser Prozess ist in der evolutionären Logik verankert: Hat ein Organismus Ressourcen in ein Objekt gesteckt, muss dieses wertvoll sein, sonst wäre die Investition irrational. Die psychologische Besitzzuweisung aktiviert Belohnungssysteme im präfrontalen Kortex und erzeugt eine emotionale Bindung an das Ergebnis der Arbeit (S008).

Im Kontext der Softwareentwicklung bedeutet das, dass eine architektonische Entscheidung, an der das Team monatelang gearbeitet hat, als eleganter und zuverlässiger wahrgenommen wird, als sie tatsächlich ist. Kritik an dieser Entscheidung löst Abwehrmechanismen aus, weil ein Angriff auf den Code als Angriff auf die investierte Arbeit und damit auf die Kompetenz des Teams wahrgenommen wird.

NIH‑Syndrom als Schutz der Gruppenidentität

Das „Not‑Invented‑Here“-Syndrom verstärkt sich, wenn eine externe Lösung die Gruppenidentität bedroht. Ein Team, das Ressourcen in die Entwicklung eines eigenen Frameworks investiert hat, betrachtet eine fertige Lösung nicht als Werkzeug, sondern als symbolische Ablehnung seiner Kompetenz. Das hängt mit der fundamentalen Attributionsfehler zusammen: Externe Lösungen werden dem Glück oder Marketing zugeschrieben, während eigene als Meisterleistung gelten.

Die Gruppenidentität verstärkt den Effekt durch soziales Feedback: Teammitglieder bestätigen gegenseitig die Überlegenheit der eigenen Lösung und erzeugen so eine Informationsblase. Der Bestätigungsfehler sorgt dafür, dass jegliche Daten zu den Vorteilen externer Lösungen neu interpretiert oder abgelehnt werden.

Stadienmanifestation im Entwicklungszyklus

In der Planungsphase zeigt sich der IKEA‑Effekt als überschätzte Selbsteinschätzung: Das Team unterschätzt die Komplexität der Aufgabe, weil es sich den Erfolg bereits psychologisch zugesprochen hat. In der Codierungsphase verschärft die Planungsfehlschluss das Problem, da das Team ungern anerkennt, dass der gewählte Ansatz suboptimal ist – das würde eine Neubewertung des investierten Aufwands erfordern.

Beim Testen äußert sich das NIH‑Syndrom als unzureichende Prüfung des eigenen Codes und überkritische Haltung gegenüber Alternativen. In der Wartungsphase verteidigt das Team weiterhin die architektonischen Entscheidungen, selbst wenn sie technischen Schulden erzeugen, weil das Eingeständnis eines Fehlers bedeutet, dass der investierte Aufwand umsonst war.

Neurobiologische und evolutionäre Grundlagen

Das Belohnungssystem des Gehirns (ventrales Striatum und orbitofrontaler Kortex) wird nicht nur bei Ergebniserreichung aktiviert, sondern auch beim Investieren von Aufwand in dessen Erreichung. Dieses System ist evolutionär für Jäger‑ und Sammler angepasst, bei denen der Energieaufwand für ein Objekt (Werkzeugherstellung, Beuteverarbeitung) tatsächlich mit dessen Wert korrelierte.

In der modernen Softwareentwicklung arbeitet dieses System gegen uns: Die Komplexität einer Aufgabe und der investierte Aufwand garantieren nicht mehr die Optimierung einer Lösung. Zudem lässt die Illusion der Kontrolle Entwickler*innen glauben, sie verstehen die Konsequenzen ihrer architektonischen Entscheidungen vollständig, was die kritische Bewertung mindert.

Faktor	IKEA‑Effekt	NIH‑Syndrom	Einfluss auf das Projekt
Verzerrungsquelle	Psychologische Besitzzuweisung durch Aufwand	Schutz der Gruppenidentität	Überschätzte Bewertung eigener Entscheidungen
Aktivierte kognitive Systeme	Belohnungssystem, emotionale Bindung	Soziales Feedback, Blindspot der Voreingenommenheit	Reduzierung der Objektivität der Bewertung
Kritische Phase	Nach erheblichen Zeitinvestitionen	Bei Auftreten konkurrierender Lösungen	Zeitplan und Budget werden ausgedehnt
Manifestation im Code	Unwille zu Refactoring, Überkomplexität	Verzicht auf fertige Bibliotheken, Funktionsduplizierung	Technische Schulden und Sicherheitslücken
Verstärkender Faktor	Öffentliche Präsentation der Lösung	Größe und Zusammenhalt des Teams	Architekturelle Entscheidungen werden unveränderlich

Die Kombination dieser Mechanismen erzeugt ein besonders gefährliches Szenario in der IT: Das Team überschätzt nicht nur die Qualität seines Codes, sondern widersetzt sich aktiv externen Daten, die dieser Einschätzung widersprechen. Das führt zu technischen Schulden, Terminverzögerungen und potenziellen Sicherheitslücken, die aufgrund des Ergebnisverzerrungs unbeachtet bleiben – wenn das System funktioniert, war die Architektur also korrekt.

Разработка, продуктовые команды, закупки, архитектура, исследования.

Beispiele für den IKEA-Effekt und das NIH-Syndrom in der Softwareentwicklung

Fall 1: Entwicklung eines eigenen Content-Management-Systems in einem Startup

Im Jahr 2019 beschloss ein Team von acht Entwicklern in einem Moskauer EdTech-Startup, ein eigenes Content-Management-System zu entwickeln, anstatt eine fertige Lösung wie Contentful oder Strapi zu implementieren. Das Projekt war für drei Monate mit einem Budget von 25.000 € geplant.

Die Entwickler waren überzeugt, dass sie eine flexiblere und besser auf ihre Bedürfnisse zugeschnittene Lösung schaffen könnten. Nach acht Monaten befand sich das System jedoch noch in der Entwicklung, die Kosten hatten 80.000 € überschritten, und das Team hatte 70 % seiner Zeit mit Debugging und Fehlerbehebung verbracht, anstatt am Kernprodukt zu arbeiten. Der IKEA-Effekt zeigte sich darin, dass die Entwickler emotional an ihrer Lösung hingen und Vorschlägen, fertige Alternativen zu nutzen, Widerstand leisteten (S001).

Das NIH-Syndrom verstärkte diese Voreingenommenheit: Das Team hielt externe Lösungen für „nicht passend zu ihrer Spezifik“ obwohl in Wirklichkeit 80 % der Funktionalität den Anforderungen entsprachen. Die Entwickler ignorierten die Warnungen des Projektmanagers und schrieben weiter Code, investierten immer mehr Arbeit und emotionale Energie. Hätte das Team in der dritten Entwicklungswoche eine ehrliche Kostenanalyse durchgeführt und die Kosten einer fertigen Lösung mit den prognostizierten Ausgaben verglichen, hätte es 55.000 € einsparen und die Markteinführung um fünf Monate beschleunigen können.

Fall 2: Neuschreiben eines Frameworks in einem großen IT-Unternehmen

Der Systemarchitekt eines Unternehmens mit 200 Entwicklern initiierte ein Projekt zum vollständigen Neuschreiben des internen Frameworks, das in 15 Microservices verwendet wurde. Das Framework war vor fünf Jahren geschrieben worden und benötigte ein Update, funktionierte jedoch stabil. Der Architekt überzeugte das Management, dass die neue Version um 40 % schneller und um 60 % einfacher zu warten sein würde.

Das Projekt dauerte 18 Monate statt der geplanten neun. Ein Team von 12 Personen war vollständig mit dem Neuschreiben beschäftigt, während die übrigen Entwickler den neuen Framework nicht nutzen konnten und mit dem alten weiterarbeiteten. Die Kosten beliefen sich auf 150.000 €. Als das neue Framework schließlich ausgerollt wurde, stellte sich heraus, dass der Leistungszuwachs nur 12 % betrug und die Wartungskomplexität auf demselben Niveau blieb (S003).

Der IKEA-Effekt und das NIH-Syndrom zeigten sich hier darin, dass der Architekt emotional an seiner Vision des neuen Frameworks hing und nicht anerkennen wollte, dass die alte Lösung gut funktioniert. Das Entwicklerteam, das Monate Arbeit in den neuen Code investiert hatte, verteidigte ihn gegen Kritik, selbst als die Daten zeigten, dass die Verbesserungen minimal waren. Hätte das Unternehmen ein Pilotprojekt in einem Microservice durchgeführt und die Ergebnisse ehrlich bewertet, hätte es erkannt, dass ein komplettes Neuschreiben des Frameworks nicht sinnvoll ist und stattdessen gezielte Optimierungen am alten Code hätte vornehmen können.

Fall 3: Entwicklung eines eigenen ORM anstelle von Hibernate

Ein Team von fünf Java-Entwicklern in einem FinTech-Unternehmen beschloss, eine eigene ORM‑Schicht (Object-Relational Mapping) zu entwickeln, anstatt Hibernate zu verwenden, das in der Branche Standard ist. Die Entwickler hielten Hibernate für „zu schwer“ und „nicht auf ihre spezifischen Datenbankabfragen optimiert“.

In 14 Monaten schrieb das Team 25 tausend Zeilen Code für das eigene ORM. Als das System jedoch in die Produktion ging, traten kritische Probleme auf: Speicherlecks, fehlerhafte Transaktionsverarbeitung und Caching‑Probleme. Die Fehlerbehebung dauerte weitere vier Monate. Gleichzeitig stellte sich heraus, dass Hibernate dieselben Aufgaben dank integrierter Optimierungen bewältigt hätte und über bessere Dokumentation sowie eine stärkere Community zur Unterstützung verfügt (S008).

Das NIH-Syndrom und der Dunning‑Kruger‑Effekt führten dazu, dass die Entwickler ihre Fähigkeit überschätzten, eine bessere Lösung zu schaffen als ein bewährtes Werkzeug. Der IKEA-Effekt verstärkte diese Voreingenommenheit: Je mehr Code die Entwickler schrieben, desto stärker hingen sie an ihrer Lösung und desto weniger kritisch bewerteten sie sie. Hätte das Team eine ehrliche Anforderungsanalyse durchgeführt und die Funktionalität von Hibernate mit den tatsächlichen Projektbedürfnissen in der Planungsphase verglichen, hätte es erkannt, dass die fertige Lösung ihre Anforderungen vollständig abdeckt und es ermöglicht, sich auf die Geschäftslogik statt auf die Infrastrukturentwicklung zu konzentrieren.