Wie stellt man den Stand der Technik sicher? (Part 2 - während Entwicklung/Wartung)

Bereits im Rahmen der Entwicklung einer Software werden oft Verletzungen des Standes der Technik eingebaut. Kaum ein Entwicklungsteam kann von sich behaupten, dass die Software an allen Stellen dem Stand der Technik entspricht. Allzuoft erkennt man bereits während der Entwicklung Mängel, findet aber keine Zeit sie auszubauen. Dasselbe gilt für die Wartung - bereits bestehende Mängel werden nicht ausgebaut und neue Mängel kommen durch Wartungsarbeiten bzw. verabsäumte Anpassungen der Software an den geänderten Stand der Technik hinzu. Die Frage lautet also: Wie kann man während der Softwareentwicklung verhindern, dass Mängel hinsichtlich des Standes der Technik eingebaut werden bzw. dass verabsäumt wird, diese auszubauen?

Alle Menschen machen Fehler, das gilt selbstverständlich auch für gute Softwareentwickler. Aber unterschiedliche Softwareentwickler machen unerschiedliche Fehler, darum ist die Wahrscheinlichkeit, dass ein Fehler (oder ein Mangel hinsichtlich des Standes der Technik) in eine Software überhaupt eingebaut wird, deutlich geringer, wenn mehrere Entwickler gleichzeitig den Code schreiben. Dafür gibt es unterschiedliche Techniken wie Pair-Programming oder Mob-Programming. Auch mittels Design- und Code-Reviews findet man Fehler und Mängel hinsichtlich des Standes der Technik. Darum sollten ebenfalls Techniken wie verpflichtende Pull-Requests, Quality-Gates und Statische Code-Analyse eingesetzt werden.

Dieselben Techniken kann man auch in der Wartung einsetzen um sicherzustellen, dass bestehende oder durch die Änderung des Standes der Technik hinzugekommene Mängel ausgebaut werden: Beispielsweise durch die Einführung einer Quality-Gate, die sicherstellt, dass am Beginn jeder Release jedes Tool und jedes Framework aktualisiert und hinsichtlich des Standes der Technik überprüft wird.

All die genannten Techniken funktionieren aber hinsichtlich des Verhinderns bzw. Aufdeckens von Mängeln nur dann gut, wenn auf folgendes geachtet wird:

• Blick auf das Ganze und nicht nur auf den kleinen Teil, an dem gerade gearbeitet wird. Ansonsten sieht man den Wald vor lauter Bäumen nicht und bekommt vielleicht guten Code, aber weder eine Architektur, noch ein Design gemäß Stand der Technik.
• Collective Code Ownership und konstruktiver Umgang miteinander. Ansonsten bestimmen einzelne und andere trauen sich nicht Kritik zu üben.
• Merciless Refactoring und Software Craftmanship. Ansonsten entsteht bzw. verkommt Software schnell zu einem billigen, schlechten, bald unwartbarem und somit abzulösendem Produkt.
• Breites Wissen und Wissen darüber, was den Stand der Technik ausmacht. Ansonsten kennt man keine Alternativen bzw. kann nicht entscheiden, welche Alternative die bessere ist.

Nicht einmal die besten Teams beherrschen all diese Techniken - insbesondere fehlt zumeist das Wissen, was den Stand der Technik bei Software ausmacht, was zu den üblichen Mängel hinsichtlich des Standes der Technik führt. Wie schon bei den diesbezüglichen Überlegungen vor Beginn der Umsetzung eines Softwareprojektes, hilft auch hier der Einsatz eines unabhängigen Experten. Dieser kann nicht nur bei der Einführung und Optimierung der genannten Techniken helfen, sondern auch mit wenigen Stunden Aufwand pro Woche während der Entwicklung die Verantwortung und Haftung für den Stand der Technik übernehmen.

Fazit: Ein Team muss eine Reihe von Techniken und Verhaltensweisen einsetzen, um während der Entwicklung / Wartung eine Software am Stand der Technik zu halten. Damit das nicht nur zielgerichtet, sondern auch günstig erfolgt, wird der Einsatz eines unabhängigen Experten dringend angeraten.