Embed Size (px)
Citation preview
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
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
Matthias Bohlen
Kunden von A bis Z
Einführung:
NIH - Not invented here Was ist das? Wie äußert sich das?
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.
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!
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.
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.
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.
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?"
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
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!
Die Ursachen für NIH
Warum verhalten Menschen sich so?
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
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!
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
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!
Abhilfe
Wie können wir das NIH Syndrom heilen?
Matthias Bohlen
Machen wir' s wie ein Arzt
• Anamnese - was ging schief?
• Diagnose - woran liegt's?
• Therapie beginnen
• Regelmäßig nachsteuern
• Nachuntersuchung, Erfolgskontrolle
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?
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!
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
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
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?
Präventivmaßnahmen
Wie kann ich NIH in meinem Projekt verhindern?
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
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!"
Matthias Bohlen
Zusammenfassung / Diskussion
• "Not invented here" Syndrom ist kostspielig
• Früh erkennen
• Individuell therapieren
• Entschlossen vorbeugen
• Fragen?
• Anregungen?
http://www.mbohlen.de
+49 170 772 8545
