Alex Rampp

Ideen für produktive Softwareentwickler

Worum geht es hier?

Ich bin gerade dabei, einen neuen Blog über Softwareentwicklung zu konzipieren. Du wirst dich sicher fragen, „noch ein weiterer Blog übers programmieren?“ – Jein. Klar geht es in diesem Blog auch ab und an über Programmierthemen, allerdings immer mit einem bestimmten Fokus: Qualität.

Qualität?

Für Softwarequalität gibt es viele Definitionen, vereinfacht lässt sich Softwarequalität allerdings wie folgt definieren:
  • sie funktioniert
  • der Quellcode ist leicht verständlich
  • neue Anforderungen lassen sich einfach und schnell umsetzen
  • ein Benutzer kann die Software intuitiv bedienen

Was ist das Problem?

Unsere Branche hat immer noch ein Qualitätsproblem. Insbesondere im Bereich Wartbarkeit und Code Qualität werden oft Kompromisse zugunsten kurzfristiger Ziele eingegangen. Das mag in manchen Fällen durchaus gerechtfertigt sein, oft fallen einem diese Entscheidungen aber früher oder später auf die Füße. Durch die Bewegung weg von schwerwiegenden Prozessen, hin zu leichtgewichtigen, agilen Entwicklungsmodellen nimmt die Verantwortung des Softwareentwicklers zu. Die Aussage „not my job“ gilt nicht mehr. Jeder Einzelne ist für die Qualität des abgelieferten Produkts verantwortlich. Und hier ist das Problem. Allzu oft habe ich selbst Aussagen wie „das ist fertig, ich muss nur noch Unit-Tests schreiben“ oder „Fertig, aber irgendwann müsste man das mal refaktorieren“, gehört. Aus irgend einem Grund lassen wir Entwickler uns immer wieder dazu hinreisen halbfertige Arbeiten abzuliefern.

Die Lösung?

Eine Einfache Lösung kann ich leider auch nicht bieten. Es liegt auch nicht an fehlenden Methoden und Techniken. Ich denke es ist eher eine Frage der eigenen Einstellung. Hierzu gibt es den Begriff „Software Craftsmanship“. Damit ist gemeint, dass wir Softwareentwickler uns nicht als Industriearbeiter, sondern als Handwerker verstehen sollten. Hast du einen (guten) Handwerker schon einmal „Fertig“ sagen gehört, während die Hälfte noch im Rohbau ist – wir Softwareentwickler machen das jeden Tag. Um die Qualität in unserer Branche zu heben brauchen wir keine schwerwiegenden Prozesse. Stattdessen muss jeder Einzelne dazu bereit sein, das Bestmögliche abzuliefern. Das heißt manchmal auch, Konflikte mit Kunden oder Vorgesetzten einzugehen falls die Qualität zur Disposition steht. Dass das nicht Einfach ist versteht sich von selbst. Ich möchte mit meinem Blog meine Erfahrungen, die ich in den letzten Jahren über diese Thematik gesammelt habe teilen. Dabei wird es teilweise um harte technische Themen, zum Teil auch um die sozialen Aspekte in einem Entwicklerteam gehen. Zudem freue ich mich über spannende Diskussionen mit meinen Lesern.

Ein paar Fragen an Dich

  • Was hältst Du von diesem Konzept?
  • Welche Fragen, Probleme oder Wünsche hast Du im Bezug auf Softwarequalität?
  • Wie wird Qualität in Deinenm Team gelebt, bzw. gibt es überhaupt ein Qualitätsproblem?
 PS: Dieser Artikel ist Teil der ersten Aufgabe der Blog Momentum Challenge 2016

2 Kommentare

  1. Gute Idee, je mehr über das Thema gesprochen wird, desto besser!

    Für mich geht es bei dem ganzen Thema primär um Professionalität:
    Es ist mittlerweile denke ich allgemein bekannt, warum es wichtig ist auf Qualität in der Softwareentwicklung wert zu legen, auch und vor allem schon aus wirtschaftlichen Aspekten.
    Wenn also Dinge wie „Clean Code“ oder „Unit Tests“ von Entwicklern ignoriert werden oder noch nicht einmal bekannt sind, ist das aus meiner Sicht amateurhaftes und schlechtes Arbeiten.

    Ich habe bisher in einer mittelständischen Firma sowohl in SCRUM-Teams als auch in einem etwas klassischeren Umfeld (V-Modell) gearbeitet. Außerdem war ich über ein halbes Jahr in einem Großkonzern tätig und berate seit einem halben Jahr einen großen IT-Dienstleister im öffentlichen Dienst.
    Überall habe ich ähnliches erlebt:
    – „Wir haben keine Zeit Unit Tests zu schreiben oder etwas zu refaktorieren“
    – „Hauptsache es funktioniert“
    – „Das ist nicht meine Aufgabe“
    – Leute die sagen „Clean Code und Unit Tests sind wichtig“ und dann selbst nichts davon umsetzen

    Was sind die Gründe dafür?
    Ich glaube, dass tatsächlich fehlende Verantwortung das Hauptproblem ist. Es ist relativ einfach, etwas hinzubekommen, was irgendwie funktioniert. Und schlussendlich ist das das Einzige, was zunächst wichtig ist. Selbst wenn es Maßnahmen wie verpflichtende Code-Reviews gibt, ist es meist relativ einfach qualitativ minderwertigen, ungetesteten Code in Produktion zu bringen („Ich habe keine Zeit das jetzt noch schön zu machen“, „Es funktioniert doch erst mal“, …).
    Implizit wird die Verantwortung damit an Andere abgeschoben. Es funktioniert jetzt irgendwie und später soll sich jemand anderes drum kümmern, wenn das Kartenhaus zusammenfällt.
    Ganz krass ist dieses Phänomen übrigens gerade in dem öffentlichen IT-Dienstleister, da dort Verträge mit externen Entwicklern nur jeweils 6 Monate laufen.
    Schnell irgendwas hinhacken und nach 6 Monaten woanders hingehen erscheint vielen da eine gute Idee zu sein.

    Für mich besteht eine mögliche Lösung aus mehreren Komponenten:
    – Organisationen müssen weg von dem tayloristischen Modell (Hirn und Verantwortung oben, dumme Arbeiter unten). Eigentlich gibt es auch bereits genug Beispiele in der Richtung aber von Anderen zu lernen scheint für viele Unternehmen ein abwegiger Gedanke zu sein
    – Die Ausbildung mehr in die Richtung gehen. Einfach Code zu produzieren der hoffentlich irgendwie funktioniert ist einfach nicht genug. Neben Qualität gehören dazu aus meiner Sicht auch Dinge wie Softwaredesign und Requirementsengineering – einfache Programmierer braucht bald (eigentlich jetzt schon) niemand mehr
    – Schlussendlich sind auch wir, d.h diejenigen die sich aktiv mit dem Thema beschäftigen, aus meiner Sicht verpflichtet das Wissen und die richtige Einstellung an den Nachwuchs weiterzugeben

    Ich bin auf deine Ansichten zu dem Thema gespannt!

    VG
    Dominik

  2. Hallo Dominik,

    da stimme ich Dir voll zu! Gerade an dem IT-Dienstleisterbeispiel sieht man, dass es eine Einstellungssache ist. Allerdings wird gerade in diesem Bereich mit sehr harten Bandagen gekämpft und wenn man zu langsam/teuer ist ist man raus aus dem Geschäft.
    Das macht es natürlich verlockend, mit einer schnellen, billigen Lösung beim Kunden zu punkten. Allerdings funktioniert das nur kurzfristig. Die richtige Balance zwischen „Clean Code nach Lehrbuch“ und schnellen pragmatischen Lösungen zu finden ist schwierig, aber nicht unmöglich. Ich beschäftigte mich gerade selbst viel mit diesem Spannungsfeld und werde das wohl auch öfter zum Thema hier machen.

    Grüße
    Alex

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© 2019 Alex Rampp

Theme von Anders NorénHoch ↑