Not invented here
"Soft Bugs" finden und reparieren
Matthias Bohlen <mbohlen@mbohlen.de>
Matthias Bohlen
Agenda
• Was ist das NIH-Syndrom?
• Warum ist NIH wichtig?
• Wie kann man das Syndrom erkennen?
• Wie kann...
Matthias Bohlen
Matthias Bohlen – das Profil
• Unabhängiger Berater
– Architektur, Software-Engineering
– Objekt- und Komp...
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 akz...
Matthias Bohlen
So fängt NIH an...
• Entwickler bemerkt, dass er Objekte in einer
Datenbank speichern muss
• Er glaubt, da...
Matthias Bohlen
Das Schicksal nimmt seinen Lauf...
• "Oh, bisher kann ich nur String-Attribute im
Objekt, ich brauche aber...
Matthias Bohlen
Das Grauen...
• "Hmmm, ich brauche wohl auch persistente
Beziehungen zwischen den Objekten."
• Der Prototy...
Matthias Bohlen
...nimmt Formen an...
• "Hmmm, 1:n Beziehungen und n:m Beziehungen sind
vom Kunden auch gefordert."
• "Ach...
Matthias Bohlen
Schließlich der Kollaps
• Jetzt wird das Ausmaß der Anforderungen endlich klar:
– Oh, ich muss abgeleitete...
Matthias Bohlen
Risiken bei NIH
• Entwicklungskosten steigen im Projekt
• Wartungskosten steigen nach dem Projekt
• Qualit...
Matthias Bohlen
Beispiele für NIH
• Warum entwickeln Menschen so etwas?
Und zwar immer wieder?
– Persistenzframeworks
– Lo...
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 bekan...
Matthias Bohlen
In Wahrheit...
• Die Chemie im Gehirn
– Lust:
• Melatonine, Oxytocine
• Serotonin, Dopamin
– Stress:
• Adr...
Matthias Bohlen
Der "Heureka"-Effekt
• Prof. Dr. Henning Scheich
Leiter des Leibniz-Instituts für
Neurobiologie in Magdebu...
Matthias Bohlen
Abgekürzt heißt das:
• Etwas neu erfinden ist halt cool!
• Und macht mehr Spaß als etwas
Existierendes ric...
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
• ...
Matthias Bohlen
Anamnese
• Frühindikatoren beachten
– Ein Feature geht sehr schnell, danach dauert alles länger
als erwart...
Matthias Bohlen
Diagnose - woran liegt's?
• Mangelnde Tool-Marktkenntnis
• Selbstüberschätzung
• Tunnelblick
• Unterforder...
Matthias Bohlen
Therapie-Ansätze
• Für "Stars"
– Bremsen, anhalten: reflektieren, dokumentieren lassen
– Blick für den ges...
Matthias Bohlen
Therapie-Ansätze (2)
• Für Junioren
– Grenzen aufzeigen
– Schulungen, Trainings, Coaching anbieten
– "Hack...
Matthias Bohlen
Erfolgskontrolle
• Design-Entscheidungen von
erfahrenen Architekten begleiten lassen
– insbesondere die "M...
Präventivmaßnahmen
Wie kann ich NIH in meinem Projekt
verhindern?
Matthias Bohlen
Vorbeugen statt heilen
• Architekturteam installieren
– Vorschreiben, dass neue Komponenten nur in
Absprac...
Matthias Bohlen
Weiter vorbeugen
• Feedback geben
– "Christian hat ein Open Source
Persistenzframework mit Erfolg eingeset...
Matthias Bohlen
Zusammenfassung / Diskussion
• "Not invented here" Syndrom ist kostspielig
• Früh erkennen
• Individuell t...
Nächste SlideShare
Wird geladen in …5
×

Not invented here – wie Teams besser zusammenarbeiten können

369 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
369
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
4
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Not invented here – wie Teams besser zusammenarbeiten können

  1. 1. Not invented here "Soft Bugs" finden und reparieren Matthias Bohlen <mbohlen@mbohlen.de>
  2. 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. 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. 4. Matthias Bohlen Kunden von A bis Z
  5. 5. Einführung: NIH - Not invented here Was ist das? Wie äußert sich das?
  6. 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. 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. 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. 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. 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. 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. 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. 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. 14. Die Ursachen für NIH Warum verhalten Menschen sich so?
  15. 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. 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. 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. 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. 19. Abhilfe Wie können wir das NIH Syndrom heilen?
  20. 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. 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. 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. 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. 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. 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. 26. Präventivmaßnahmen Wie kann ich NIH in meinem Projekt verhindern?
  27. 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. 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. 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

×