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