Suche
Studie zu den Faktoren für schlechte Code-Qualität

Warum gute Entwickler schlechten Code schreiben – Die Agile-Perspektive

Natali Vlatko

Was sind die Faktoren, die Team-Mitglieder und deren Coding-Fähigkeiten beeinflussen? Wie kann ein agil produziertes Projekt in sich zusammenfallen, wenn es um die Software-Qualität geht? Wir haben ein wenig in akademischer Literatur gestöbert, um es herauszufinden.

Zweifellos ist jeder Entwickler schon einmal auf schlechten Code gestoßen, sei es von jemand anderem, sei es auf den eigenen. Dafür gibt es sicher eine ganze Menge verschiedener Gründe. Wir aber wollen uns etwas genauer ansehen, welche davon mit der Etablierung agiler Konzepte am Arbeitsplatz zu tun haben.

Ein kanadisches Forscher-Duo hat für einen Zeitraum von zehn Monaten die Vorgänge in einer großen Telekommunikationsfirma beobachtet und eine Studie über ein firmeninternes Software-Projekt veröffentlicht. Der Bericht basiert auf wöchentlichen Status-Meetings, in denen technische Probleme und Verwaltungsfragen auf den Tisch gebracht wurden.

Beschrieben werden Fälle, die die Komplexität von institutionellen Faktoren aufzeigen sollen und auf zehn Probleme verweisen, die einen negativen Einfluss auf die Software-Qualität hatten. Die zur Frage stehende Projektstruktur war lose am Wasserfall-Modell orientiert, allerdings wurden auch Parallelen zu streng agil arbeitenden Teams gezogen.

Probleme mit äußeren Einflüssen

Die Forscher Mathieu Lavallée und Pierre N. Robillard von der Polytechnique Montréal in Kanada glauben, dass ihre Studie bislang fehlende empirischen Daten zur Frage liefern, „wie institutionelle Faktoren die Software-Qualität beeinflussen können.“ Ihre Arbeit schließt hier eine Lücke, die in der Forschung bislang scheinbar ignoriert wurde.

Im Blick auf ein zwei Jahre lang laufendes Forschungsprojekt, das sie für einen firmeninternen Kunden konzipiert hatten, konnten Lavallée und Robillard Probleme innerhalb des Teams feststellen, die direkt auf äußere Einflüsse zurückzuführen waren. Einige dieser Probleme waren durch die verteilte Software entstanden, mit der das Team arbeitete, beispielsweise durch interne Abhängigkeiten auf verschiedene Frameworks, die Legacy Code unterstützten.

Andere Probleme, wie die Verwaltungspolitik, waren vom Management verursacht worden sowie von Entwicklern, die bessere Ergebnisse erzielen konnten, wenn sie Gefälligkeiten außerhalb des eigenen Software-Engineering-Prozesses einforderten. Das bedeutet wiederum, dass neuere Team-Mitglieder oder sogenannte Programmiernovizen, gar nicht in die Falle der äußeren Einflüsse tappen konnten, die dem Projekt angeblich helfen sollten:

For example, sometimes third party entities would refuse a CR on the basis that the change would violate the core functionality of their libraries. Inexperienced developers or managers would often accept these refusals at face value. However, employees with experience on the capability of the external libraries would often challenge these decisions… talking to the right person at the third party entity was the key factor of success.

Lavallée und Robillard merken an, dass dieses Verhalten oft tief in der institutionellen Kultur eines Unternehmens verwurzelt ist. Das ist auch der Fall, wenn von Seiten des Managments oder von Senior-Developern starker Druck ausgeübt wird, wenn dem Team Befehle erteilt werden und mit negativen Konsequenzen gedroht wird. Denn die Befehlsempfänger haben eventuell nicht alle notwendigen Informationen zur Hand, wenn sie mit den Anforderungen konfrontiert sind. Das Ergebnis sind falsch gesetzte Prioritäten: „Die gegebene Struktur eines Teams zu übergehen, unterminiert dessen Entscheidungsfindungsprozesse..“

Lesen Sie zum Thema auch: Ist Agile gescheiter(t)?

Agile in einer nicht-agilen Umgebung

Ian Allison von der University of West Scotland hat eine auf mehreren Fallanalysen gegründete Studie über die institutionellen Faktoren vorgelegt, die die Fortschritte der Softwareentwicklung  im Jahr 2010 beschränkt hatten. Allison untersucht vor allem zwei Probleme in der Herstellung von qualitativ hochwertiger Software:

  • Wenn innerhalb agiler Teams, die in einer nicht agil operierenden Organisation arbeiten, ein Konflikt ausbricht, setzt sich in der Regel der Wille der Organisation durch. Die agilen Prinzipien verschwinden dann mehr oder weniger.
  • Stetiger Druck der Institution auf eines ihrer Entwickler-Teams zwang dieses, seine Arbeitsweise zu ändern, ungeachtet des Widerstands, den ein Teil des Teams entgegensetzte.

Der Trickle-down-Effekt, den solch Untersuchungen mit sich bringen, steht in enger Beziehung mit der Tatsache, dass der Einfluss des Unternehmens auf das Team größer ist, als der des Teams auf das Unternehmen. Wie Lavallée und Robillard feststellen, kann man annehmen, dass die institutionellen Faktoren die Produktqualität beeinflussen können, während die Unternehmenswerte Einfluss darauf haben, wie die Teams Entscheidungen treffen.

Das kanadische Duo fasst seine Studie dahingehend zusammen, dass diese Probleme vielleicht nicht unbedingt den Projekterfolg gefährden, sicherlich aber die Qualität der produzierten Software, und damit wiederum Maintenance-Kosten nach sich ziehen:

If the Module developed in this project is successfully deployed, it will likely be used for decades to come. The design flaws introduced because of the organizational issues presented here will no doubt come back to haunt at least a generation of developers to come, as the code written today will be tomorrow’s legacy code. Is this the kind of legacy we want to leave for future software developers?

Schlechter Code trotz Scrum

Michael James, der über Mitarbeiter geschrieben hat, die schlechten Code produzieren, stimmt damit überein, dass diese Arbeitsweise kontraproduktiv ist und dass schlechter Code ein Problem aller ist.

By the time I learned to program in the 1970s, it was already well established that the cost of maintaining software is far greater than the initial cost of writing it. This problem has only gotten worse as software has grown more complex.

Als ein Anhänger und Lehrer von Scrum kann er die Tatsache nur bestätigen, dass schlechter Code auch von Entwicklern stammen kann, die angeben, Scrum zu praktizieren. Er will sogar davon gehört haben, dass dies als Grund für den schlechten Code angegeben wurde. Er glaubt, dass Pair Programming, Test-Driven Development (TDD) und eine unermüdliche Refaktorierung die geeigneten Mittel sind, um schlechten Code zu vermeiden.

Die bislang genannten Probleme sind nicht neu in der Agile-Welt. Dennoch werfen sie einige Schlaglichter auf die Möglichkeiten, agile Prozesse zu manipulieren, auszubremsen und misszuverstehen. Und das führt zu bescheidenen Arbeitsergebnissen.

Stimmen Sie zu? Was sind Ihre Erfahrungen mit agiler Softwareentwicklung und dem Ergebnis in der Software-Qualität?

Verwandte Themen:

Geschrieben von
Natali Vlatko
Natali Vlatko
An Australian who now calls Berlin home, via a two year love affair with Singapore. Natali was an Editorial Assistant for JAXenter.com (S&S Media Group).
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: