Sisyphos wäre heute Software-Entwickler

Regelmäßig lese ich „The World of IT“ und „Bernds Management Blog“ auf den Seiten der iX, die von OOSE-Chef Bernd Österreich, Jutta Eckstein und Nicolai Josuttis geschrieben werden. Mit durchschnittlich einer Veröffentlichung pro Monat ist es auch ein leichtes jede Veröffentlichung zu lesen. Falls Sie auch diese Blogs lesen: Ist Ihnen schon einmal aufgefallen, daß jeder der genannten eine für eine bestimmte Grundhaltung steht? An welche ich dabei denke will ich heute für mich behalten, besonders da ich mich mit dem letzten Beitrag von Nicolai Josuttis auseinander setzen möchte.

„Software-Putzmänner und die nächste IT-Revolution“ stand da eines Abends im September in meinem RSS-Reader und ich habe interessiert die verlinkte Seite aufgerufen. Der Text hat mich so beschäftigt, daß auch ihn auch jetzt noch kommentieren möchte.

Josuttis schreibt darin über einem Vortrag auf der Agile 2008 zum Thema Software-Qualität, der von Robert C. Martin gehalten wurde. Martin stellt fest, daß wir in der Software-Branche zu viel Mist produzieren. Vorallen tun wir das, weil einfach zu wenig Zeit dafür zur Verfügung steht um sauber zu arbeiten zwischen all den Budgetplänen, Tagessätzen und Releaseterminen. Insofern ist das Sujet bekannt und die meisten von uns können das wohl aus der einen oder anderen Erfahrung bestätigen.

Das eigentlich interessante ist, daß Josuttis das wohl aus eigener Erfahrung kennt und auch darlegt, wie er versucht diesem Problem beizukommen und damit glatt die nächste Revolution in der IT-Welt vorhersagt.

Josuttis versucht dem Problem beizukommen, in dem die Entwicklung von Fachlichkeiten vom „Sauermachen“ trennt. Es gibt also zwei Gruppen. Die einen schreiben fleißig Code und die anderen bringen ihn in Ordnung. Schlechter Code ist demnach in Ordnung, da er später glattgezogen wird. An die großen Hypes Agilität und SOA anknüpfend entwickelt er diesen Gedanken weiter und stellt die Frage, warum wir nicht endlich schlechten Code akzeptieren, schließlich haben wir mit der Agilität sich wandelnde Anforderungen akzeptiert und sogar kultiviert und SOA das gleich mit heterogenen Systemen getan. Schlußendlich sollten wir aufhören, schlechten Code zu bekämpfen, sondern sinnvoll damit umgehen.
So sehr er mit vielem auch Recht hat, umso mehr irrt er hier doch und kommt zu einem falschen Schluß. Schlechter Code ist zu bekämpfen.

Eine allgemein gültige Definition von gutem Code gibt es nicht. Daher für aber viele von Qualität. Mir gefällt am besten die DIN-Definition, wonach Qualität „die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse (Qualitätsanforderungen) zu erfüllen“ ist. Zugegebener Maßen klingt das etwas sperrig und erschließt sich nicht direkt, denn was sind „abgeleitete Erfordernisse“. Qualität hat viele Ausprägungen, wie da wären:

  • Funktionalität
  • Zweckdienlichkeit
  • Sicher
  • Robustheit
  • Benutzbarkeit
  • Zuverlässigkeit
  • Änderbarkeit
  • Portierbarkeit
  • Prüfbarkeit
  • Geschwindigkeit

Jeder wird zugeben, daß eine Software, die nicht die geforderten Funktionen bringt aus Kundensicht nichts wert ist. Insofern ist Funktionalität ein hinreichendes Qualitätsmerkmal, aber allein nicht ausreichend. Je länger eine Software lebt, umso wichtiger werden auch Merkmale wie Wartbarkeit und Änderbarkeit und können zum Schluß mehr über den Erfolg Ihrer Software entscheiden als die eigentliche Funktionalität.

Natürlich muß man am Code verzweifeln, wenn man die perfekte Architektur und eine konsistente Einhalt von Codierrichtlinien erwartet und hofft, daß alle Entwickler den gleichen Stil pflegen und sich mit der gleichen Hingabe ihrer Aufgabe widmen. Die Welt ist nicht perfekt und wir sind es nicht, warum sollte es unsere Software sein? Perfekte Software ist schlichtweg unmöglich. Sie ist unmöglich, weil sich die Welt rund um die Software ständig ändert. So ändern sich die Anforderungen, im Idealfall werden sie konkreter und damit für alle besser. Wir wissen besser, was unser Kunde will und der Kunde erhält eher das, was er braucht. So ändern sich die Tools mit denen wir arbeiten. Werden sie besser, so verbessert sich unser Stil Software zu entwickeln - oder wirft uns um Jahre zurück. So ändern auch wir uns. Mit jedem Projekt wächst unser Wissen und Können, auch wenn wir uns ehrlicher Weise auch bei ählichen Fehlern immer wieder selber stellen. Das war wir gestern geschrieben haben, ist uns Wissen, Können und Vermögen von gestern und das kann das Beste gewesen sein, was wir zu diesem Zeitpunkt leisten konnten.
Allerdings ist das alles kein Grund schlechte Software zu akzeptieren. Oder möchten Sie schlechte Software benutzen. Jeder von uns erwartet, daß der Geldautomat zu jeder Tageszeit funktioniert und nicht irgendwie, sondern richtig. Und freut sich, wenn das zu übernehmende Projekt gut geführt und die Sofware sauber implementiert ist.

Vielmehr sollten wir uns umso mehr bemühen gute Software mit perfekten Code zu entwicklen. Wie schon weiter oben geschrieben ist das Ziel nicht erreichbar, doch wenn wir es uns als Ziel setzen werden die Ergebnisse weit besser sein, als wenn wir uns von vornherein nur mit Mittelmäßigkeit begnügen. Denn sobald wir dies verinnerlicht haben, werden wir uns mit noch weniger zufrieden geben.

Tags: , , ,

Hinterlasse eine Antwort