K1 - Warum bessere Software schreiben?

Was könnte die Motivation für Entwickler sein, um nicht nur gute, sondern immer ein Stück bessere Software zu schreiben? Für mich gibt es da zwei Gründe, die ich als allgemeingültig ansehe:

• Zufriedenheit
• Professionalität

Zufriedenheit

Jeder Entwickler möchte doch ein Projekt zufrieden abschließen, oder? Und natürlich wollen alle Entwickler als professionell gelten. Die Zufriedenheit kann nur jeder mit sich selbst ausmachen, und eine wichtige Rolle dabei spielen Ziele. Das Minimalziel für einen Entwickler in schlecht durchgeführten Projekten ist oft die Software lauffähig und quasi korrekt auszuliefern. Quasi soll hier bedeuten, dass der Entwickler sich durchaus bewusst ist, dass es unter der Haube noch einige Probleme gibt, doch die grundsätzliche Korrektheit auf jedenfall gegeben ist. Meist führen dynamische Parameter zur Laufzeit zur Aufdeckung von Fehlern, weil in solchen Projekten auch selten gründlich getestet wird.
Ich denke kein Entwickler kann auf Dauer zufrieden sein, wenn er immer nur dieses Minimalziel erreicht. Daher sehe ich die Weiterbildung als weiteren wichtigen Aspekt, um Zufriedenheit zu erreichen. Jedes Projekt ist auch eine Möglichkeit sich fachlich weiterzubilden und um Erfahrungen zu sammeln. Diese neuen Fachkenntnisse können dann dazu beitragen, dass man auch in schlecht durchgeführten Projekten sein Minimalziel mit weniger Stress und Überstunden erreicht.

Die Hauptmerkmale um Zufriedenheit zu erreichen sind also Zielerfüllung und Weiterbildung.

Nun hat der Entwickler in letzter Konsequenz ebenfalls die Aufgabe auch die Ziele der anderen Projektteilnehmer zu erfüllen. Der Kunde und das Unternehmen haben eigene Projektziele:

Das Unternehmen bzw. Vorgesetzte möchten die vertraglich vereinbarten Anforderungen erfüllt haben und optimalerweise mit einer hohen Effizienz, beides hat wirtschafltich positive Auswirkungen.

Der Kunde achtet natürlich auf Korrektheit, d.h. die Erfüllung der funktionalen Anforderungen, sowie auf Qualität und Termintreue. Die Qualität beschränkt sich dabei sehr oft auf die Nicht-funktionalen Anforderungen, z.B. Performance und Sicherheit, sowie Design und Benutzbarkeit (Usability).

Die Erfüllung dieser Ziele führen mit Sicherheit bei jedem Entwickler zu hoher Zufriedenheit. Da das Erreichen dieser Projektziele aber sehr grundlegend ist (also nichts besonderes), wird Zufriedenheit auf Dauer keine ausreichende Motivation für bessere Software sein. Dies führt uns zur Professionalität.

Professionalität

Was bedeutet eigentlich Professionalität? Darüber haben sich bereits einige bekannte und wohl professionelle Softwareentwickler Gedanken gemacht und an dieser Stelle möchte ich die Clean Code Developer Initiative zitieren:

Professionalität = Bewusstheit + Prinzipien

Was genau CCD damit ausdrücken möchte lesen sie bitte direkt auf der Homepage nach. Ich bin selbst ein großer Fan des CDD Wertesystems und kenne keine bessere Zusammenfassung von Prinzipien und Praktiken in der Softwareentwicklung.

Ein Begriff fällt im Berufsleben immer wieder, wenn von Professionalität die Rede ist, und das nicht nur in der Softwareentwicklung. Entwickler werden oft als Problemlöser bezeichnet, und wer eine effektive und schnelle Lösung entwickelt, der wird dann als pragmatisch bezeichnet. Dies wird allgemein und besonders von Personalern und Management als positive Eigenschaft angesehen, Pragmatiker haben einen guten Ruf.

Ich habe jedoch eine geteilte Meinung zu Pragmatismus, obwohl ich selbst schon als pragmatisch bezeichnet wurde. Das Problem dabei war, dass ich meine so genannten pragmatischen Lösungen selten bis nie als qualitativ hochwertig angesehen habe. Oft war die Lösung für meine Vorgesetzten und den Kunden völlig in Ordnung, aber diese Leute hatten auch ein anderes Verständnis von Softwarequalität. So, und wenn ich von effektiven und schnellen Lösungen höre, dann denke ich meist an Quick & Dirty Code. Entwickler müssen immer mal wieder auf hart-codierte Strings, duplizierten Code oder ähnliche Code Smells zurückgreifen aufgrund von Termindruck oder Zeitmangel für eine saubere Integration. In meinem Fall waren das oft die Momente in denen von pragmatischen Lösungen die Rede war. Und daher denke ich, dass der Begriff Pragmatismus in der Softwareentwicklung sehr oft missbraucht wird - bewusst oder unbewusst.

Das klingt jetzt vielleicht sehr pessimistisch, aber ich halte es für einen Fakt, dass bei jeder pragmatischen Lösung die Qualität vernachlässigt wird. Meiner Erfahrung nach benötigen pragmatische Lösungen oft eine Nachbereitung in Form von Refactoring. Und hier beginnt für mich die Professionalität, denn Profis werden erst zufrieden sein, bis eine Lösung bestimmten Qualitätsrichtlinien entspricht, unabhängig von Lob und Anerkennung von Kunden und Vorgesetzten.