Günstigere Software durch weniger Tests

the next big thing  –  93 Kommentare

Softwareentwicklung gilt als teure Disziplin. Nicht nur Fachfremde sind häufig überrascht, wie viel Geld die professionelle Entwicklung einer Software bedarf. Code, Tests, Dokumentation und Integration, das alles will bezahlt werden. Doch woran lässt sich sparen?

Im Projektmanagement gibt es eine einfache Grundregel. Für ein Projekt lassen sich zwei der drei Faktoren Zeit, Umfang und Kosten optimieren. Hat man zwei Faktoren ausgewählt, muss man beim dritten Einbußen hinnehmen. Legt man beispielsweise Zeit und Umfang fest, ergeben sich daraus die notwendigen Kosten. Legt man hingegen Zeit und Kosten fest, ergibt sich daraus der mögliche Umfang. Diese Regel ist allseits bekannt – und wird regelmäßig ignoriert.

Götz & Golo

"Götz & Golo" ist eine gemeinsame Serie von Götz Martinek und Golo Roden. Der eine ist Geschäftsführer der sodge IT GmbH, der andere CTO der the native web GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Götz findet sich im Blog von sodge IT. Die Fragestellung zu diesem Beitrag lautete: "Günstigere Software durch weniger Tests"

In zu vielen Projekten wird statt einer vernünftigen Planung auf Augenhöhe nämlich ein möglichst hoher Umfang in möglichst kurzer Zeit für möglichst wenig Geld diktiert. Versucht man dann tatsächlich, ein derart "geplantes" Vorhaben durchzuziehen, ist das Ergebnis in 99,9 Prozent der Fälle, dass sich die Software verspätet, sie nicht alle gewünschten Funktionen enthält und außerdem deutlich teurer wird als erwartet.

Projekte werden falsch geplant …

Doch auch das frühzeitige Kommunizieren der absehbaren Probleme nützt in der Regel nichts: Der Termin zur Markteinführung steht bereits fest, der Funktionsumfang ist wichtigen Kunden bereits versprochen, und die Kosten waren von vornherein knapp kalkuliert.

Die einzige Option, um die getätigten Zusagen zu halten, besteht dann zumeist darin, Druck aufzubauen. Die irrige Annahme besteht dabei darin, dass Entwickler schneller denken, wenn man sie nur genug drängt. Tatsächlich ist das genaue Gegenteil der Fall: Je mehr Druck man ausübt, desto geringer wird die Leistungsfähigkeit.

… gehen zu Lasten der Qualität …

Das wiederum ist zumindest den Entwicklern durchaus bewusst, also suchen sie wiederum sich ein anderes Ventil. Das einzige, was nun noch verbleibt, ist die Qualität. Also beginnen Entwickler, die ersten Tests außen vor zu lassen. Code wird nicht mehr aufgeräumt. Auch die Dokumentation des Codes erscheint auf einmal nicht mehr so wichtig zu sein, sie lässt sich schließlich später noch nachreichen.

Kurzfristig scheint das Vorgehen tatsächlich Erfolg zu haben: Die Entwicklungsgeschwindigkeit steigt, und im Idealfall lässt sich das Projekt sogar noch pünktlich und mit allen versprochenen Funktionen im geplanten finanziellen Rahmen zu Ende bringen. Die logische Schlussfolgerung lautet, dass das Projekt sogar früher und günstiger fertig geworden wäre, hätte man nur von Anfang an auf die Tests, das Aufräumen des Codes und die Dokumentation desselben verzichtet. Günstigere Software durch weniger Tests!

… und werden zunehmend teurer

Das böse Erwachen stellt sich spätestens dann ein, wenn die nächste Version der Software entwickelt oder die ersten Fehler behoben werden sollen. Vermeintlich einfache Erweiterungen und Änderungen brauchen zunehmend mehr Zeit. Die ersten erfahrenen Entwickler kündigen, wodurch wertvolles Wissen verloren geht. Doch zum Glück gibt es eine einfache Lösung: Man ergänzt das Projekt um neue Entwickler, denen zwar jegliche Erfahrung mit dem Projekt fehlt – aber das lässt sich durch Quantität sicher wettmachen, so die Vermutung.

Leider stellt sich diese Vermutung rasch als falsch heraus, denn statt besser wird alles nur noch schlimmer. Das dürfte gemäß Brook's Law zwar wenig überraschend sein – in zahlreichen Projekten ist das jedoch eine stets neue Erkenntnis. Am Ende bleibt eine Software, deren Codebasis weder aufgeräumt noch wartbar ist, deren Weiterentwicklung deshalb zunehmend teurer wird und die schließlich irgendwann durch eine Neuentwicklung abgelöst werden muss.

Damit bei dieser Neuentwicklung nicht erneut böse Überraschungen auftreten, gilt es dann, nicht agil und flexibel vorzugehen, sondern die Zeit, den Umfang und die Kosten von vornherein strikt zu planen und festzulegen. Damit ist, so die Hoffnung, alles dafür getan, dass diese Entwicklung nun aber mit Sicherheit gelingt …

Fazit

Es liegt auf der Hand, wie die Geschichte weitergehen wird, und dass sie sich in genau gleicher Form wiederholen wird. Die Essenz davon ist, dass immer wieder dieselben zwei grundlegenden Fehler gemacht werden:

  1. Zeit, Umfang und Kosten gleichzeitig zu optimieren bedeutet, an der Qualität zu sparen.
  2. An der Qualität zu sparen bedeutet, dem Projekt langfristig massiv zu schaden.

Wer also günstigere Software möchte, muss genau das Gegenteil vom intuitiv Anzunehmenden machen. Es darf gerade nicht weniger Aufwand in Tests, Refaktorisierung, Dokumentation & Co. gesteckt werden. Denn nur wer ein tragfähiges Fundament hat, das regelmäßig gehegt und gepflegt wird, ist langfristig in der Lage, darauf stabil und sicher aufzubauen.

Das spart zwar kurzfristig kein Geld, aber langfristig schon – und wer möchte schon Software entwickeln, von der man bereits während der Entwicklung weiß, dass sie von minderwertiger Qualität ist?

tl;dr: Kurzfristig an der Qualität zu sparen, macht die langfristige Erweiterbarkeit und Wartbarkeit von Software zunichte. Deshalb ist es wichtig, im Zweifelsfall den Umfang zu reduzieren oder die Zeit und die Kosten zu erhöhen, um ein zukunftsträchtiges Fundament aufzubauen, das auf lange Sicht bestehen kann.