Software wird in Teams gemacht. Menschen werden oft unerwartet zu Teams zusammengeschlossen. Sie bauen dann in den Teamprozess genauso viele Bugs ein wie in die Software. “Not invented here” gehört zu den bekanntesten und teuren Syndromen. Sie erfahren in dieser Session, wie solche Verhaltensweisen entstehen, wie Sie sie erkennen und beheben können, um mehr Spaß und Erfolg im Projekt zu haben.

1. Not invented here
"Soft Bugs" finden und reparieren
Matthias Bohlen <mbohlen@mbohlen.de>

2. Matthias Bohlen
Agenda
• Was ist das NIH-Syndrom?
• Warum ist NIH wichtig?
• Wie kann man das Syndrom erkennen?
• Wie kann man es therapieren?
• Welche Präventivmaßnahmen kann man ergreifen?
• Q&A Session

3. Matthias Bohlen
Matthias Bohlen – das Profil
• Unabhängiger Berater
– Architektur, Software-Engineering
– Objekt- und Komponententechnologien
– Modellgetriebene Software-Entwicklung, MDA
• Dienstleistungen:
 Analyse, Design, Architektur
 Project jump start
 Technische Projektleitung
 Therapie für Projekte in der Krise
 Beratung
 Schulung
 Trainings
 Coaching

4. Matthias Bohlen
Kunden von A bis Z

5. Einführung:
NIH - Not invented here
Was ist das? Wie äußert sich das?

6. Matthias Bohlen
NIH definieren
• Es gibt zwei Bedeutungen von NIH:
– ich mache etwas selbst, was es bereits gibt
– ich akzeptiere einen Vorschlag nicht, weil der
Vorschlagende aus einer anderen Gruppe kommt
• In diesem Vortrag geht es um NIH im ersten
Sinne, nicht im zweiten.

7. Matthias Bohlen
So fängt NIH an...
• Entwickler bemerkt, dass er Objekte in einer
Datenbank speichern muss
• Er glaubt, dass O/R-Mapper wie JPA oder
Hibernate überdimensioniert sind:
– "Ich brauche ja nur eine Zeile pro Objekt in eine
Tabelle zu schreiben, dabei jedes Attribut in eine
eigene Spalte, mehr nicht."
– "Das sollte mittels JDBC in einem Tag zu realisieren
sein."
• Tatsächlich: Der Prototyp läuft in einem Tag!

8. Matthias Bohlen
Das Schicksal nimmt seinen Lauf...
• "Oh, bisher kann ich nur String-Attribute im
Objekt, ich brauche aber auch Integer und
Double-Werte."
• Der Prototyp wird um
Datenformatierungsklassen angereichert.
• Der zweite Tag ist um.

9. Matthias Bohlen
Das Grauen...
• "Hmmm, ich brauche wohl auch persistente
Beziehungen zwischen den Objekten."
• Der Prototyp wird um
Fremdschlüsselverwaltung angereichert.
• Bis es tut, ist eine Woche um.

10. Matthias Bohlen
...nimmt Formen an...
• "Hmmm, 1:n Beziehungen und n:m Beziehungen sind
vom Kunden auch gefordert."
• "Ach, ich kann Objekte nur laden und speichern, aber
nicht updaten".
• Der Prototyp wird innerhalb 4 Wochen um
Zwischentabellenverwaltung und das Laden und
Speichern von Collections ergänzt.
• Weitere 4 Wochen werden benötigt, um den Prototyp
um Schattenkopieverwaltung und Differenzermittlung
für UPDATE-Statements zu ergänzen.

11. Matthias Bohlen
Schließlich der Kollaps
• Jetzt wird das Ausmaß der Anforderungen endlich klar:
– Oh, ich muss abgeleitete Klassen auch können. Und
polymorphe Beziehungen auch!
– Oh Schreck, verschiedene Datenbanken muss ich
unterstützen und Caching für die Performance brauch
ich auch!
– Und was ist eigentlich mit Multi-User-Zugriffen?
• "Jetzt muss ich ja alles refaktorisieren und große Teile neu
machen!"
• Entwickler gibt auf und gesteht, dass er nun doch Hibernate
einsetzen wird. Der Teamleiter fragt: "Und was hast Du die
letzten 8 Wochen gemacht?"

12. Matthias Bohlen
Risiken bei NIH
• Entwicklungskosten steigen im Projekt
• Wartungskosten steigen nach dem Projekt
• Qualität ist gering, da wenig getestet
– "Frischer" (nicht-trivialer) Code hat immer
mehr Bugs als "reifer" (oft benutzter,
getesteter und debuggter Code).
• Bekannte Standardfehler werden noch
einmal gemacht
• Best practices werden nicht genutzt

13. Matthias Bohlen
Beispiele für NIH
• Warum entwickeln Menschen so etwas?
Und zwar immer wieder?
– Persistenzframeworks
– Loggingframeworks
– Validierungsframeworks
– Druckaufbereitung und Reporting
– Data Binding
– Rule Engines
– XML Parser
– GUI-Generatoren
– Cache-Verwaltung
– Sogar Verschlüsselung, unvorstellbar!

14. Die Ursachen für NIH
Warum verhalten Menschen sich so?

15. Matthias Bohlen
Vermeintliche Ursachen
• Für den mit dem Hammer ist alles ein Nagel
• Ich fühle mich wohl mit meinen bekannten Tools
• Ich selbst kann es sicher am besten
• Ich mache das mal schnell, die anderen brauchen immer
so lange...
• Ich brauche ja keine Riesenlösung, sondern nur schnell
dieses kleine Programm...
• Es tut nicht ganz das was ich will
• Eine Library-Funktion aufzurufen kostet zu viel CPU-Zeit
• Ich wusste nicht, dass die Funktion / Library / der Code
existiert
• Ich hätte es anders gemacht

16. Matthias Bohlen
In Wahrheit...
• Die Chemie im Gehirn
– Lust:
• Melatonine, Oxytocine
• Serotonin, Dopamin
– Stress:
• Adrenalin, Cortisol
• Glückshormone bei/nach großer Anstrengung
– die schwere Geburt
– das Erlegen des großen Tieres nach schnellem Lauf
– die Auflösung eines intellektuellen Problems
• Bekanntes Muster aus der Natur!

17. Matthias Bohlen
Der "Heureka"-Effekt
• Prof. Dr. Henning Scheich
Leiter des Leibniz-Instituts für
Neurobiologie in Magdeburg:
– "Aha-Effekt führt zur Ausschüttung
von Dopamin, das die Motivation
aufrecht erhält und weitere Opiat-
Ausschüttung anregt."
– "Gehirn belohnt sich selbst, bringt sich
in gute Stimmung, wenn es etwas
gelöst hat und speichert es auch noch
ab!"
http://www.ifn-magdeburg.de/en/departments/auditory_learning_and_speech/index.jsp

18. Matthias Bohlen
Abgekürzt heißt das:
• Etwas neu erfinden ist halt cool!
• Und macht mehr Spaß als etwas
Existierendes richtig zu evaluieren und
kosteneffizient einzusetzen!

19. Abhilfe
Wie können wir das NIH Syndrom heilen?

20. Matthias Bohlen
Machen wir's wie ein Arzt
• Anamnese - was ging schief?
• Diagnose - woran liegt's?
• Therapie beginnen
• Regelmäßig nachsteuern
• Nachuntersuchung, Erfolgskontrolle

21. Matthias Bohlen
Anamnese
• Frühindikatoren beachten
– Ein Feature geht sehr schnell, danach dauert alles länger
als erwartet
– Es kommt für den User keine sichtbare Funktionalität
mehr hinzu!
– Der Code sieht übermäßig kompliziert aus
– Die Bugs nehmen nicht ab
• Reviews durchführen
– Aufgabenstellung überprüfen: Musste dieser Code
überhaupt entwickelt werden?
• Design-Entscheidungen nachlesen
– "Make or Buy" - wurde das überhaupt erwogen?

22. Matthias Bohlen
Diagnose - woran liegt's?
• Mangelnde Tool-Marktkenntnis
• Selbstüberschätzung
• Tunnelblick
• Unterforderung
– "Star", "Local Hero", "Programmiergenie"
• Mangelnde konkrete Anforderungen
– Ich entwickle Frameworks, da kenne ich die
Anforderungen selber!
• Kulturelle Vorprägung
– Bei den indischen Kollegen existiert zuwenig Angst vor
Komplexität - die wäre aber angebracht!

23. Matthias Bohlen
Therapie-Ansätze
• Für "Stars"
– Bremsen, anhalten: reflektieren, dokumentieren lassen
– Blick für den gesamten Software-Lebenszyklus schärfen
• Mit der Programmierung ist die Software nicht abgeschlossen, es
kommen noch Wartung und Betrieb
– Falls das Ergebnis schon deployt ist:
• Star in den Second Level Support für das setzen, was er selbst
entwickelt hat
– Wenn alles nichts hilft:
• Auf tatsächlich neue, kurze, komplexe Aufgabe ansetzen
• Planungshilfe leisten, um Rückfall in NIH zu verhindern
• Gründlichen, "dickfelligen" Arbeiter als Peer an die Seite stellen
• Star von der Aufgabe schnell wieder abziehen

24. Matthias Bohlen
Therapie-Ansätze (2)
• Für Junioren
– Grenzen aufzeigen
– Schulungen, Trainings, Coaching anbieten
– "Hackathons" und Code Camps organisieren
Hier können die "Stars" helfen
– Einen erfahrenen Peer im Alltag an die Seite stellen

25. Matthias Bohlen
Erfolgskontrolle
• Design-Entscheidungen von
erfahrenen Architekten begleiten lassen
– insbesondere die "Make or Buy" Entscheidungen!
• Regelmäßige Code-Reviews durchführen
• Regelmäßige Erfolgskontrolle
– Gibt es jetzt weniger Bugs?
– Kommt für den User jetzt mehr sichtbare
Funktionalität heraus?
– Arbeiten die Leute jetzt an wirklich wichtigen,
projektspezifischen Non-Standard-Aufgaben?

26. Präventivmaßnahmen
Wie kann ich NIH in meinem Projekt
verhindern?

27. Matthias Bohlen
Vorbeugen statt heilen
• Architekturteam installieren
– Vorschreiben, dass neue Komponenten nur in
Absprache mit den Architekten anzulegen sind
• Regelmäßige Rückbetrachtungen am Ende
einer Iteration durchführen
– Wieviel User-relevante Funktionalität geschaffen?
– Wieviele neue Komponenten entstanden?
• Ausbildung
– Den Blick über das eigene Projekt hinaus weiten
– Leute einmal im Jahr auf eine Konferenz schicken
– Teilnahme an einem weltweit tätigen Open Source
Projekt ermöglichen

28. Matthias Bohlen
Weiter vorbeugen
• Feedback geben
– "Christian hat ein Open Source
Persistenzframework mit Erfolg eingesetzt und
dadurch viel Zeit gespart, danke, Christian!"
– "Sandra hat in der Kaffeepause erfahren, dass das
Problem mit den Caches im Parallelprojekt bereits
gelöst ist und hat es bei uns genauso gelöst,
danke Sandra!"
– "Frank hat erfahren, wie die Leute von apache.org
das implementiert haben und konnte unsere leicht
fehleranfällige Eigenimplementierung entfernen,
danke, Frank!"

29. Matthias Bohlen
Zusammenfassung / Diskussion
• "Not invented here" Syndrom ist kostspielig
• Früh erkennen
• Individuell therapieren
• Entschlossen vorbeugen
• Fragen?
• Anregungen?
mbohlen@mbohlen.de
http://www.mbohlen.de
+49 170 772 8545