JAX 08: Not invented here: "Soft Bugs" finden und reparieren

von Thomas Bahn,
assono GmbH, Standort Kiel,



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
Veranstaltung Fachbeitrag JavaScript Sonstiges

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie wollen eine individuelle Lösung? Kontaktieren Sie uns

Weitere interessante Artikel

Sie haben Fragen oder möchten eine Demo anfordern?

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Gerne erstellen wir eine individuelle Demo für Sie.

Wir verwenden Ihre Daten, um Sie einmalig per E-Mail zu kontaktieren. Wir geben Ihre Daten nicht an Dritte weiter. Siehe: Datenschutzhinweise
assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Techn. Hotline: +49 4307 900 403
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de