Wider den Verfall von Software


22.02.2017 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

Software unter­liegt einem schleichen­den Verfall

Software besteht aus Nullen und Einsen. Des­halb könnte man an­nehmen, dass Soft­ware dauer­haft halt­bar ist. Anders als Maschinen, die im Freien stehen und damit der Witterung aus­ge­setzt sind, ist die Soft­ware in unseren Rechnern und Rechen­zentren sicher auf­ge­hoben. Doch das ist ein Irrtum.

Es gibt ver­schiedene Ein­flüsse, die für die Soft­ware den gleichen Effekt wie die Wit­terung auf Maschinen hat. Selten bis nie läuft Soft­ware für lange Zeit un­ver­ändert in der gleiche Be­triebs­umgebung. Da­mit haben wir schon zwei Ein­fluss­faktoren, die es näher zu be­trachten gilt: Die ge­wollten Ver­ände­rungen und die Betriebs­umgebung.

Verfall durch Aktu­a­li­sie­rungen der Betriebs­umgebung

Betrachten wir zuerst den Fall, dass wir eine Soft­ware vor uns haben, die perfekt die fach­lichen An­forde­rungen um­setzt und diese sich im be­trach­teten Zeit­raum auch nicht ver­ändern. Hier sehen wir, dass sich die Be­triebs­umgebung ver­ändert. Unter Be­triebs­umgebung ver­stehen wir dabei alles, was unter­halb der eigent­lichen App­li­ka­tion für deren funk­tio­nieren er­forder­lich ist.

  • Hardware
  • Betriebssystem
  • Laufzeit­umgebungen, beispiels­weise für Java oder .NET
  • Software-Bib­lio­theken
  • Netz­werk­kompo­nenten (bei ver­netzten oder re­dun­dant aus­ge­legten Applikationen)

In der Regel wird eine Betriebs­organi­sation diese Be­triebs­umgebung selbst­ständig auf einem einiger­maßen aktuel­len Stand halten:

  • Hardware wird aus­ge­tauscht, wenn sie defekt wird oder ab­ge­schrieben ist.
  • Patches und neue Ver­sionen für Be­triebs­system, Lauf­zeit­um­geb­ungen und Soft­ware-Bib­lio­theken werden eingespielt.
  • Netz­werk­komponenten werden in gleicher Weise aktuell gehalten.

Damit verändert sich etwas am Ge­samt­system. Nehmen wir das Bei­spiel „Lauf­zeit­umgebung“. Wenn man hier Java ak­tua­li­siert, dann sind in der Regel die be­stehen­den Pro­gram­me weiter lauf­fähig. Aber die „schönen“ neuen Features werden da­durch natür­lich noch nicht ge­nutzt. Die Soft­ware ver­altet, ohne, dass man an dem Source-Code auch nur ein Zeichen ver­ändern muss.

Verfall durch Weiterentwicklung

Die Weiter­ent­wicklung von Soft­ware ist der Normal­fall. Kaum eine Soft­ware bleibt längere Zeit un­ver­ändert. Hier können nun mehrere Effekte zum Tragen kommen, die dazu führen, dass Soft­ware altert:

  • Gelegentlich soll es vor­kommen, dass die Weiter­ent­wicklung unter Zeit- oder Kosten­druck ge­schieht. Wie wir wissen, gilt die alte Weis­heit, dass man nur die Wahl hat, zwei der drei Stell­größen „Zeit“, „Kosten“ und „Qualität“ zu be­stim­men und die ver­bleibende Größe sich daraus dann auto­ma­tisch er­gibt. In diesem Fall heißt das, dass unter Zeit- oder Kosten­druck tech­nische Schulden in Kauf ge­nom­men werden und die Quali­tät da­runter leidet.
  • Wissens­defizit bei der Weiter­ent­wicklung kann auch diesen Effekt haben. Ent­wickler kommen neu dazu, wenn eine Weiter­ent­wick­lung an­steht. Diese kennen den Code nicht und sind erst einmal kon­ser­va­tiv: „Code, dessen Sinn ich nicht ver­stehe lasse ich erst einmal un­verändert. Lieber kopiere ich die Teile, die ich brauche und ver­ändere sie wie ge­for­dert. Dann weiß ich genau, dass in dem Fall, den ich be­arbei­te genau mein Code auf­ge­rufen wird und keine mir un­be­kan­nten Seiten­effekte auf­treten können.“

Verfall wird in Weiter­entwicklungs­kosten gemessen

Der Verfall kann uns ja prinzipiell egal sein, solange er keine spür­baren Aus­wirk­ungen nach sich zieht. Die Aus­wirk­ungen, die immer als nicht zu ver­nach­lässigen an­ge­sehen werden, sind Kosten. In diesem Fall wollen wir die fik­tiven Kosten für eine gleich­artige Weiter­ent­wicklung des Systems zu Grund legen. Diese Kosten sind des­halb fiktiv, weil jegliche Er­weite­rung eines Systems nur ein­mal vor­ge­nommen würde. Da­nach sind die Features vor­handen und müssen nicht noch ein­mal ge­baut werden.

Aus meiner Er­fahr­ung werden die Kosten für eine Er­wei­te­rung im Laufe der Zeit immer höher. Dieser Effekt ist mehr als linear. Das heißt um­ge­kehrt, dass das System immer schneller auf das Ende zu­strebt. Dies ist in der neben­stehenden Ab­bil­dung illustriert.

Oftmals kann man dann be­obach­ten, dass als Reak­tion auf diese steigen­den Kosten die An­forde­rungen an die Weiter­ent­wicklung eines Systems ein­ge­schränkt werden. Damit kommt die IT ihrem Auftrag, das Business zu unterstützen und mit den Systemen dem Be­darf zu be­friedi­gen, nicht mehr adäquat nach.

Refactoring: Sisyphos lässt grüßen

Gegen die Entropie zu kämpfen, fordert an­dauern­de An­streng­ungen, wie schon Sisyphos im klas­sischen Alter­tum fest­stel­len musste. In der Soft­ware-Ent­wick­lung be­deutet das, dass man Arbeit in eine Soft­ware in­ves­tie­ren kann, um die zu­künf­tigen Weiter­ent­wicklungs­kosten zu reduzieren.

Durch die Brille der Ent­wickler ge­sehen heißt das „Refactoring“. Oftmals wird Refactoring – ins­be­son­dere im Business – da­mit ver­bunden, dass die Ent­wickler die Soft­ware „schöner“ machen, ohne, dass damit neue Features ver­bunden wären. Da wird dann re­flex­artig an „Ein­sparen“ ge­dacht. Das ist aber auch aus Business-Sicht oft­mals zu kurz gesprungen.

Re­fac­to­ring wirkt den ne­ga­ti­ven Ef­fekten des Ver­falls von Soft­ware entgegen. Das heißt, dass die Wartungs- und Weiter­ent­wicklungs­kosten durch Re­fac­to­ring re­du­ziert werden. Man kann die über-linearen Kosten für Change-Re­quests (CR) nur be­dingt über­listen. Durch Re­fac­to­ring wird die Kurve nach unten ge­drückt und die Steigung zurück­ge­setzt:

Am Ende ergibt sich doch wieder eine steigende Kurve und ein über-line­arer An­stieg – zu­min­dest in den ein­zel­nen Seg­men­ten zwischen den Re­fac­to­rings. Aber in Summe sind die Kosten für CRs deutlich niedriger als in dem Szenario ohne Refactoring.

Refactoring ist ein an­dauern­der Kampf gegen den Ver­fall. Dieser wird nie ge­wonnen werden kön­nen. Trotz­dem ist es wert, diesen Kampf aus­zu­tragen – aus archi­tek­toni­scher Sicht, aber auch aus wirt­schaft­licher Sicht.

Das Ende naht

Die Kosten für CRs sind ein Effekt von ver­fal­lender Soft­ware. Der Verfall wirkt sich auch auf die Lebens­dauer von Soft­ware aus. Im Laufe der Zeit nimmt die Quali­tät der Soft­ware ab. Am Ende ist die Qualität so weit ge­sunken, dass eine Weiter­nutzung der Soft­ware nicht mehr sinn­voll mög­lich ist. Das „End of Life“ ist erreicht.

Wenn wir nun auf er­halten­de Maß­nahmen für die Soft­ware ver­zichten, dann ist der Ver­fall be­schleunigt. Am Ende steht ein wirt­schaft­licher Total­schaden: Für eine an­stehende Weiter­ent­wick­lung sind die Kosten so hoch, dass es sich lohnt, über eine Er­satz­beschaf­fung nach­zudenken.

Verfall kann wirtschaft­lich sinnvoll sein

Als „Techniker“ haben wir meistens den Re­flex, Soft­ware so gut es geht zu er­halten und dem Ver­fall ent­gegen­zu­wirken. Wenn man nur die archi­tek­tonische Brille auf hat, dann ist das auch sinn­voll und ver­ständ­lich. Trotz­dem gibt es Sze­na­rien unter denen es sinn­voll sein kann, Soft­ware ver­fallen zu lassen.

  • Wenn das ge­plante Ende des Ein­satzes der Soft­ware be­reits feststeht und nahe ist, dann kann man in der Regel auf er­haltende Maß­nahmen ver­zichten. Dies kann der Fall sein, wenn die Ab­lösung im Zuge von Kon­so­li­dierungs­maß­nahmen im Unter­nehmen schon be­schlossen ist.
  • Wenn Soft­ware „ein­ge­froren“ wird, er­gibt sich ein ähnlicher Effekt: Die Soft­ware muss zwar noch erhalten bleiben, aber Ände­rungen da­ran sind nicht mehr notwendig.

„Gib mir die Kraft zu kämpfen und die Weisheit zu sehen, wann es sich lohnt“

Als Techniker sollten wir immer für den Er­halt der Soft­ware und gegen den Ver­fall kämpfen. Re­fac­tor­ing sollte immer als Teil von Entwicklung und Weiter­ent­wick­lung von Soft­ware ver­standen werden. Trotz­dem dürfen wir den anderen Aspekten gegen­über nicht blind sein und einen Ver­fall hin­nehmen, wenn dies aus ande­ren Gründen sinnvoll ist.


Dieser Blog-Artikel steht under der Lizenz CC-BY-SA 4.0.
Die in den Blog-Beitrag eingebundenen Bilder stammen zum Teil von Pixabay und stehen alle unter der Lizenz CC-0.

Diesen Artikel bewerten
 
 
 
 
 
 
 
0 Bewertungen (0 %)
Bewerten
 
 
 
 
 
 
1
5
0
 

Artikel im Warenkorb:

0