Matthias Bohlen
Not invented here: "Soft Bugs" finden und reparieren

2 Arten des NIH-Syndroms:

• Allles selbst machen müssen
• Vorschläge von außen nicht annehmen
  
  Im Vortrag geht es um die erste Variante.
  
  Beispiel
  Einfacher, flacher JDBC-Zugriff
  mit Datentypenkonvertierung
  mit persistenten Beziehungen
  mit m:n-Beziehungen
  usw.
  
  STATT: gleich etwas Fertiges nehmen (z. B. Hibernate)

Risiken bei NIH

• Entwicklungskosten
• Wartungskosten
• Qualität gering, da wenig getestet
• bekannte Standardfehler macht man noch einmal
• Best Practices werden nur teilweise genutzt - wenn überhaupt

Beispiele

• Persistenzframeworks
• Loggingframeworks
• Validierungsframeworks
• Druckaufbereitung und Reporting
• Data Binding
• Rule Engines
• XML Parser
• GUI-Generatoren
• Cache-Verwaltung
• sogar Verschlüsselung!

Vermeintliche Ursachen

• Für den mit dem Hammer ist alles ein Nagel
• Ich fühle mich wohl mit meinen bekannten Tools
• Es tut nichts ganz das, was ich will.
• Ich brauche ja keine Riesenlösung, sondern nur schnell diese kleine Programm...
• Ich wusste nicht, dass die Funktion/Library/... schon gibt
• Ich hätte es anders gemacht

In Wahrheit


Die Chemie im Gehirn

• Lust
• Stress

Glückshormone bei/nach großer Anstrengung

• die schwere Geburt
• das Erlegen des gro0en Tieres nach schnellem, Lauf
• die Auflösung eines intellektuellen Problems

Bekanntes Muster aus der Natur



Abgekürzt

• Etwas neu erfinden ist halt cool!
• Und es macht mehr Spaß als etwas Existierendes richtig zu evaluieren und kosteneffizient einzusetzen!

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

Diagnose - woran liegt's?

Mangelnde Tool-Marktkenntnise

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!

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 nicht hilft:

• Auf tatsächlich neue, kurze, komplexe Aufgabe ansetzen
• Planungshilfe leisten, um Rückfall in NIH zu verhinden
• Gründlichen, "dickfelligen" Arbeiter als Peer an die Seite stellen
• Star von der Aufgabe schnell wieder abziehen

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

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


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

Feedback geben

• Danke sagen, wenn Entwickler Fremdlösungen gewinnbringend einsetzen

Zusammenfassung

• "Not invented here"-Syndrom ist kostspielig
• früh erkennen
• individuell therapieren
• entschlossen vorbeugen