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? Wir sind für Sie da.

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