Stephan Roth - Softwareentwicklung

Obwohl man annehmen könnte, das Softwareentwicklung im Jahr 2010 schon längst der Pubertät entwachsen und wie andere Ingenieursdisziplinen auf hohen, professionellen Niveau durchgeführt wird, spricht die Realität leider eine andere Sprache. Nach wie vor sind erschreckend schlechte Statistiken im Bereich Software-Projektabwicklung ein trauriges Faktum.

Laut dem letzten CHAOS Report 2009 der US-amerikanischen Marktforschungsfirma Standish Group International Inc. wurden lediglich 32 Prozent aller Projekte erfolgreich abgeschlossen. 44 Prozent waren arg problembehaftet und damit stark gefährdet. 24 Prozent der Projekte scheiterten bzw. wurden vorzeitig eingestellt!

Nach allgemeinem Verständnis gilt ein Projekt als gescheitert, wenn für einen seiner Hauptaspekte

• Liefer- und Leistungsumfang,
• Zeit (Erreichen der Projekt-Meilensteine), oder
• Geld/Budget

die Soll-Vorgabe vom Ist-Wert nicht erreicht wird!

Leider sagt die Studie der Standish Group nichts über die Gründe, warum nach wie vor derart viele Softwareentwicklungsprojekte in erhebliche Schwierigkeiten kommen bzw. scheitern. Das Software Engineering Institute behauptet, dass 85% aller Organisationen mit der gleichzeitigen Abwicklung von zwei oder mehr IT-Projekten überfordert seien. Der Bundesrechnungshof stellte einmal fest, das wenn der Zeitrahmen nicht eingehalten werden kann, spätestens nach 2 Jahren Laufzeit jedes IT-Projekt von der Technologieentwicklung überrollt wird. John Gage von Sun Microsystems sieht mangelnde Soft-Skills als eine wesentliche Ursache: „Technology is easy – people are hard.” Kein Informatiker lernt in seiner Ausbildung, wie man mit Konflikten in einem Team umgeht, oder wie man Arbeit als auch das projektbezogene Know-how teilt (sog. Single Head of Knowledge Anti-Pattern). Andere Experten benennen Starrheit, Gängelung durch Bürokratie und Dogmatismus von Unternehmen und Organisationen als Grund für das Scheitern von Softwareentwicklungsprojekten. Dies kann sich beispielsweise im Festhalten an einmal festgelegten Strategien ebenso zeigen wie beim dogmatischen Einsatz von Programmiersprachen und Tools durch den Entwickler (sog. Golden Hammer Syndrom; Ein bevorzugter Lösungsweg oder eine Programmiersprache wird als universell anwendbar angesehen).

Als weitere Ursachen werden in Studien immer wieder genannt:

• Schlampige Anforderungserhebung, -analyse und -management.
• Zu kurze bis gar keine Designphase.
• Ständige personelle Unter- oder Umbesetzungen.
• Falsche, nicht zu dem Projekt passende Vorgehensmodelle.
• Fragile Architekturen, basierend auf Insellösungen.
• Schleichender Funktionszuwachs während der Implementierung.
• Zu große Arbeitspakete bzw. grundsätzlich zu große, komplexe Projekte.
• Testphasen (Pilotprojekte, Prototypen, Anwendertests) fallen aus Zeitmangel unter den Tisch.
• Bugs werden viel zu spät gefunden, schlimmstenfalls beim Kunden ⇒ sehr teuer, vom Imageverlust einmal abgesehen!
• Leitern von Entwicklungsabteilungen fehlt es sehr oft an Durchsetzungskraft gegenüber der zumeist rein kaufmännischen Unternehmensleitung.
• Probleme bei der Koordination und dem Management mehrerer nebeneinander her laufender Projekte (Multiprojektmanagement).
• … u.v.m. …

Und es ist erstaunlich, dass Unternehmen – obwohl durch derartig schmerzhafte Ereignisse vorgewarnt – beim nächsten Projekt sehenden Auges immer wieder in die gleiche Situation steuern. Die Bereitschaft zu einer kritischen Retrospektive und das damit einhergehende Erarbeiten von Alternativen für einen anderen Weg scheint es kaum zu geben. Stattdessen geht man – trotz der letzten, schmerzhaften Erfahrung – das nächste Projekt genau so unprofessionell an wie das Vorangegangene; eben so wie ein kleines Kind, das sich gerade an einer heißen Herdplatte die Finger verbrannt hat, und wenige Minuten später noch einmal anfassen möchte in der Hoffnung, das es dieses Mal vielleicht nicht so heiß sein wird.

Man In The Mirror

Alles in allem kann man konstatieren, das Projekte zumeist nicht an einer einzelnen Ursache scheitern, sondern an einer komplexen Verstrickung von technischen, organisatorischen, personellen, sozialen, kommunikativen, wirtschaftlichen und interessenspolitischen Faktoren. Das kann man nun als gegeben hinnehmen, man kann versuchen etwas daran zu ändern (Was zumeist auf Grund von Vorgesetzten scheitert), oder man kann sich die Frage stellen: welchen Beitrag kann ich als Entwickler dazu leisten, das ein klein wenig mehr Professionalität und Qualität in die von mir zu entwickelnde Software Einzug hält und somit die Wahrscheinlichkeit des Scheiterns, wenn auch nur im Promille-Bereich, abnimmt? „I’m starting with the man in the mirror, I’m asking him to change his ways” (Michael Jackson)

Ich bin daher vor ein paar Monaten der Initiative Clean Code Developer (CCD) beigetreten. Die von Ralf Westphal und Stefan Lieser initiierte Initiative für mehr Softwarequalität definiert ein Wertesystem aus Prinzipien, Regeln und Praktiken, welche dabei helfen sollen, Softwareentwicklung professioneller zu machen. Das CCD-Wertesystem basiert auf den Ideen des Buches "Clean Code" von Robert C. Martin.

Ein professioneller Softwareentwickler setzt sich mit dem Metier bewusst auseinander und er hat ein inneres Wertesystem. Da man nicht mal so eben von heute auf morgen zum Clean Code Developer wird, unterteilt CCD das Wertesystem in verschiedene Stufen, sogenannte Grade. Jedem dieser Grade ist eine Farbe zugeordnet. Diese Grade sind keine Hierarchiestufen, sie drücken keinen Wert aus, sondern stehen gleichberechtigt nebeneinander. Sie sind lediglich eine Hilfestellung, um einen gangbaren Weg durch die vielen Werte von CCD anzubieten. Clean Code Developer zu werden braucht Zeit, denn auch für CCD gilt das afrikanische Sprichwort:

„Lieber mit drei kleinen Sprüngen ans Ziel kommen, als sich mit einem großen Sprung die Beine zu brechen.”

Das Tolle ist: CCD kann jeder anwenden, immer und überall, auch ohne den Chef zu fragen! Es findet zunächst einmal im Kopf statt. Es ist eine Frage der Haltung, der persönlichen Arbeitskultur. CCD'ler fragen niemals, ob sie ihren Job professionell machen dürfen – sie tun es einfach!

Ich werde in Zukunft hier in meinem Blog ein paar der Werte und Prinzipien von Clean Code vorstellen und anhand von kleinen Praxisbeispielen erläutern. Wer sich darüber hinaus für CCD interessiert und sich darüber austauschen möchte, dem sei auch die XING-Gruppe Clean Code Developer ans Herz gelegt.