Provokation Softwarekrise


Abstract: Die Tatsachen sprechen dafür, daß die Softwarekrise noch immer – und das schon seit ca. 30 Jahren – existiert. So lange hat die Disziplin »Informatik« es nicht ein bißchen geschafft, sie zu beseitigen. Im Gegenteil: Die Auswirkungen sind weiterhin katastrophal: Software-Qualitäten und Produktivität blieben dürftig und kümmerlich, und zwar aus Prinzip: Theoretiker verlegen sich auf immer neue Kapriolen, etwa eine fehlgeleitete Objektorientiertheit an der Oberfläche, und die Praktiker nehmen wie immer keine guten Lehren an, obwohl es die natürlich gibt. Unsere Provokation bringt grob zur Sprache, was zur Sache gehört.

••• Copyright © by Helmut Dressler & Uwe Wagner

 Vorwort:

Formalismus – manchmal schon beinahe „Fundamentalformalismus“ – und immerwährendes, praktisches Chaos begründen die Ursachen der Softwarekrise dauerhaft. Zwar wird sie in manchen Beiträgen benannt und beschrieben – mit Google gucken! –, aber ihre Ursachen werden beinahe nie analysiert. Man meint, die SWK (terminus technicus) müsste heute längst überwunden sein und wundert sich über fulminante Beispiele, in denen sie sich immer wieder aufs neue niederschlägt. Das sind doch wohl keine Unfälle, sondern sie ergeben sich zwangsläufig wegen mangelhafter Kompetenz – in Theorie und Praxis!

 

Die Nachrichten:

… Teurer Flop INPOL - 100 Millionen DM Verlust  und 4 Jahre Verzögerung

... Fiscus Projekt steht vor dem Scheitern (CW 51/2001)
Nach 10 Jahren Entwicklung (Gesamt-Deutsche Steuer SW) will Bayern aussteigen, weil bis Ende 2001 kein Nachweis erbracht werden konnte, der eine Weiterarbeit rechtfertigt! - Jährliche Kosten in Höhe von DM 100 Mio. - Gesamtinvestition bis 2010 ca. 1, 4 Milliarden!

... KPMG setzt Projekt in den Sand (CW 48/2001)
Der Dienstleister habe bei der Einführung eines neuen Abrechnungssystems versagt!

... Arbeitsministerium ringt mit seiner IT - Landesrechnungshof moniert stark fehlerhaftes System. (CW 47/2001)
Das Arbeitsministerium Mecklenburg-Vorpommern steht offensichtlich vor einem Desaster - das "ungewöhnlich stark fehlerbehaftete Informationssystem für die Arbeitsmarktpolitik" könne nicht auf den Euro umstellen.

… und wer viele weitere Beispiele und Fachliteratur sucht, sei hingewiesen auf:

 SW-Katastrophen

 

Der Kommentar:

Seit einer Generation wird sie bekanntlich beschworen: Unsere Softwarekrise ist eine "Anwender-Softwarekrise", und wenn einer nur lange genug den Markt beobachtet hat in diesen  beinahe 30 Jahren, so gab es, um sie auszulöschen, unzählige „Methodologien“. Alle paar Jahre werden solche mit Eifer und Verve verkündet. (Jetzt waren gerade UML und Corba dran.) Die Softworker behalfen sich mit ihnen in der Vergangenheit immer mal wieder, indem sie alsbald eine Tool-gestützte Methode zum Allheilmittel erklärten, sie rücksichtslos propagierten und profitabel zu verkaufen versuchten. Meist war dem Werkzeug eine unausgegorene Theorie, aber mit einem Anspruch „a la Stein der Weisen“, unterlegt, und wer das Werkzeug bedienen konnte, war dann prompt Weisenstein-Experte, ohne dass er die komplizierte Theorie recht gefressen hätte – sie war ja auch unverdaulich –, und konnte den „Ton“ und die Richtung angeben, in denen gewerkelt wurde. Dieser „Ton“ aber stellte sich alsbald als Matsche heraus, als bloßer Schlamm; damit ließ sich kein größeres Gefäß formen und brennen. Immerhin, zwei-drei Jahre lang wurde (diese Wörter stellvertretend für alle:) „geCASEt“ und „geQARCt“, meist nur so lange wie noch keine andere Software-Methodologie auf dem Markt war, so dass jene schließlich durch diese abgelöst und aus den Abgründen der reinen Ideologiker heraus als erneuter „Paradigmenwechsel“ lanciert wurde. Später mit dem gleichen Resultat.


Einschub: im Laufe der Zeit entstanden dennoch einige Ideale, die „bleiben“. Das sind, kurz zusammengefasst:   

  • das ADT-/Modul- und Schichtenprinzip  [1]

  • demnach konsequent standardisiertes „Schnittstellentum“ [2],    

  • die Verdammung der Spaghettistrukturen [3]

  • konstruktive und analytische Qualitätssicherung von (Projekt-) Anfang an [4]

  • ein sachgerechter Datenbankentwurf [5]

  • die Vorausdefinition von „Produkten & Ergebnissen“ (Frames) als Meilensteine des Projektfortschritts [6] 

  • und ein konsequentes Projektmanagement [7], so daß während des Projekts der ursprüngliche Zeit-, Gantt- oder Netzplan gut, leicht & gerne dem tatsächlichen Ressourcen-Verbrauch angepasst wird. 

Von diesen wenigen Prinzipien könnte eine ganze Software- und Projektkultur bestens leben, wenn die Methoden nur penibel (aber einfach) ausgearbeitet, gut erklärt und als verbindlicher Standard unbeirrt eingesetzt würden. Stattdessen trifft man häufig in der Praxis diesbezüglich nur auf einen Pustekuchen mit Pfeifendeckel. 
{end of Einschub}


Warum nur können sich solche selbstverständlichen Prinzipien nicht wirklich durchsetzen? Was veranlasst immer wieder ganze Großprojektorganisationen, entweder ins Chaos zu verfallen oder mit ungeeigneten methodologischen Überbauten eine künstliche Kompliziertheit ihres entstehenden V-Vorschriftensystems zu schaffen, so dass beiden Gruppen, den „bloßen Praktikern“ und den „reinen Theoretikern“ die Projekte aus dem Ruder laufen?

Einfache Antwort: Inkompetenz in Management und Software-Produktion. Allerdings bezüglich der Software-Produktion zwei verschiedene Sorten von Inkompetenz. Alle drei wollen wir hier trefflich & polemisch, aber dennoch gar nicht übertrieben, schildern.

 

(1) Wer wird Manager in der Software-Produktion? Nun, oft jemand, der kaum Projekte zu leiten versteht, niemals viel mehr von Software gelernt und ausgearbeitet hat als damals auf der Universität, etwa als Wirtschaftsingenieurstudent, aber sich sogleich nach dem Studium hat auf die Managementschiene setzen lassen. Er hat in unzähligen Seminaren und Workshops gelernt, worauf es ankommt: Ziele bestimmen und gerade nur sie hartnäckig verfolgen! Dabei kann er sich so nebenbei auch zum „Mod“ entwickelt haben, zum „Master of desaster“. Aber er lebt bei seinen Entscheidungen zwangsläufig von den Einschätzungen und Meinungen „seiner“ Experten, die ihm berichten. Falls die nun aber  irren, weil sie sich in Niederungen oder Abgründen aufhalten, was dann?

Die o.a. Prinzipien sind ihm nämlich nicht hautnah beigebracht worden, sie gelten ihm, beiläufig, als gewöhnliche Mittel auf den Wegen zu den hehren Zielen. Er hat sie nicht erfahren können, er hat sie leider nicht mühsam fressen und also nicht wirklich verdauen müssen, bemerkt somit das Defizit nicht. „Der Manager“ bleibt an der Oberfläche, welches an sich seine Position ist, wenn er sich nur auf seine untergebene Organisation verlassen könnte. Das kann er aber manchmal nicht. Deswegen entstehen Desasterprojekte, und er weiß nicht recht, warum. Es gibt allerdings, freilich nicht gerade häufig, unübliche Ausnahmen. (Vielleicht sind Sie als Leser eine.)

Die richtigen Wörter, selbstverständlich, gehen jedem üblichen Manager leicht von den Lippen: „Objektorientiert“ sei ja nun wirklich alles sowieso und bei uns längst eingeführt. Auch hat er sich abgefunden: Man wisse ja in der gesamten Wirtschaft, dass eine nächste SAP-Release-Anpassung halt Millionen kosten werde. Auch fördert sein realer Mangel an treffenden Maßstäben die Bereitschaft, an wichtigen Moden teilzuhaben, sprich: auf Scharlatanerien hereinzufallen. Für viele moderne Software-Manager sind die o.a. Prinzipien eben nicht Lebenselixier (allein im SW-Fach, versteht sich), sondern nur Attribut, Beigabe, Akzidens ihrer Aufgaben: es kann einer sie nicht mit der nötigen Offensivkraft konsequent verfolgen und durchsetzen. Auch wüsste er nicht recht wie, und wenn er es tatsächlich tut, gerät er fast immer an bloße Praktiker (s.u.). Manch einer kann dann später „seine“ Reinfälle allerdings und zu Recht auf seine Untergebenen abwälzen, welche achselzuckend dafür jeweils einen Dienst nach neuen Vorschriften abgeleistet hatten: …

 

(2) Für die bloßen Praktiker hatte in jedem Falle da nur die Dienstanweisung gewechselt, aber sie werkelten weiter wie immer, denn – recht haben sie – da könnte ja jeder kommen und das, was immer schon so gemacht wurde, dahingehend abändern wollen, wie es noch nie gemacht worden ist. Sie glauben den unterlegten wichtigen Theorien aus der Erfahrung heraus nicht, denn diese und solche haben ihnen schon häufig das Leben schwer gemacht, ihnen nicht wirklich was genützt, sondern sind vergangen wie ihre Manager. Diese allerdings sind oft aufgestiegen, selbst wenn „die Abteilung“ nicht so erfolgreich war, da etwa die stolzen Ziele nicht erreicht wurden, gar im entferntesten nicht. Daran aber sind das Personal schuld und widerwärtige Umstände.

Unter den bloßen Praktikern mit ihrer Skepsis gegenüber neuen Ideologien hat praktisch niemand, dem die o.a. Prinzipien mehr bedeuten als schöne Theorie, eine Chance. Also müssen sie zwangsläufig auf ihrer Stufe der Inkompetenz bleiben, eben Praktiker. Das definiert so schon das „Peter-Prinzip“ (Þ rororo6793), denn wirklich gute Ergebnisse in Software können sie nicht erzielen, vielmehr schreiben sie fleißig ihre endlosen COBOL-/C-/Java-Textstränge in eilfertiger Bereitschaft schon herunter, da sie ein jeweiliges Problem noch gar nicht bis zu Ende durchdacht, sprich „strukturiert“, haben. Heutige Spaghetti in Java sind (gelehrt:) orbikular. Wenn unter den Praktikern ausnahmsweise doch mal jemand ist, dem die o.a. Prinzipien einleuchten und der sie anwenden will, stört er hier nur und wird ihm so viel Arbeit aufgehalst, dass es ihm die Flausen schon austreibt. Er, der es wissen will, wird demnächst aus „der Abteilung“ verschwinden. In Richtung der … (und da kommt er vom Regen in die Traufe) …

 

(3) Die reinen Theoretiker haben auf der Universität tüchtig gelernt: Algorithmik und von Gelehrten gelehrte Theoriegebäude. Die Gelehrten waren (alle?) sofort Gelehrte geworden, gleich nach ihrem Studium, um die akademische Karriere schleunigst zu beginnen, so dass sie nie irgendwelche vermaledeiten Sporen in entsetzlichen Großprojekten haben erwerben können. Deshalb fallen ihnen als praktische Beispiele in ihren Büchern immer nur zwei ein { (a) Professor bietet Lehrveranstaltungen an, und Studenten belegen sie; (b) Bibliothek verleiht Bücher, und Student gibt sie wieder her, nach der ersten Mahnung. } An Anwenderdatenstrukturentwürfen haben sie sich nie versucht, außer mit einem ungeliebten Bisschen für das Bibliotheksbeispiel. Auch ein komplexes Projektzusammenspiel ist ihnen nie begegnet, und Maßstab für ihre eigene Gelehrsamkeit sind die hohen Theorien der akademischen Konkurrenz. Et vice versa.

Entsprechend ebenso hoch ist das Risiko, dass sie sich in theoretische und absolute Konstrukte verirren, also Maßstäbe setzen und Verfahren propagieren, in denen das Absolute hoch geehrt, aber das Verhältnis von Nutzen zu Aufwand weitab im Nichts liegt: Ihre Software-Ideologie kann nicht an der Einfachheit ihrer Verfahren gemessen werden, weil sie nicht „einfach“ sein dürfen, sondern muss anspruchsvoll und hochgelehrt sein. Sie wird alsbald auch per se möglichst kompliziert, weil in ihr, um alle verwünschten Sonderformen des Software-Seins nach und nach abzubilden und nach einem strengen Schematismus zu modellieren, nichts ausgelassen und alles formal konzis, aber komplett, formuliert sein muss. Wer also könnte nun die Studienabgänger besser anleiten als diese professoralen Autoritäten?

Somit lassen sich jene anführen, gehen „in die Industrie“ und führen nun bald selber an. Das aber führt zu Entgleisungen der formalistischen Art: Um eine Mücke zu fangen, wird eine Fallgrube gegraben, werden also Riesenanstrengung unternommen für geringfügige Wirkung bei überbordenden Nebenwirkungen. Akuteste Beispiele sind „UseCases“ und „UML“ (sprich „ummel“!) oder, abstrus, Delphi und Wizzards, schließlich, nichtsnutzig, Corba. Es sind einige der heutigen Modemethoden; beinahe nur sie werden seminarmäßig noch gelehrt, und wer sie „beherrscht“, kann sich gut verkaufen, bleibt am Ball und ist auf der Höhe der Zeit. Sie alle aber sind Quellen für die künftige Softwarekrise; man beherrscht das Metier nicht, bei freilich höchstem theoretischen Anspruch, und die neuerlichen Reinfälle sind abzusehen.

Jetzt aber wieder zurück zu jenem bei den bloßen Praktikern ausgeschiedenen Adepten des Es-Wissenwollens. Er kommt in die hohe Schule der Beiläufigkeit beim Software-Produzieren, Hauptsache, ein Entwurfsergebnis erscheint Objektorientiert oder formal den Ansprüchen entsprechend, aber gerade nur von Benutzersicht aus, und man beherrscht die verschiedenen Diagramme. Software-Architektur kommt nicht vor, „persistente Objekte“ sind ein beiläufiges und ungeliebtes Thema. So werden rasch selbst simple Sachverhalte mit großem graphischen Gedöns modelliert und auf beeindruckende Weise zur Abbildung gebracht. Allerdings nach diesen Modellclustern ist kein System eins-zu-eins umzusetzen, sprich (pardon:) „zu programmieren“ – das aber ist für jeden Entwurf das einzige Gütekriterium überhaupt! –, sondern es wird nun an Praktiker überwiesen, die sich’s zurichten, es neu verstehen und ummodeln müssen, um es irgendwie zu implementieren. Jener Adept aber, der frühere Praktiker, bleibt nach einer Eingewöhnungszeit ratlos. Wie kann es denn auch anders sein? 

 

(1)+(2)+(3) ist beobachtbare Wirklichkeit in vielen Organisationen – natürlich nicht in allen, das wäre übertrieben – seien es quasi-beamtete oder solche der professionellen Art. („professionell“ natürlich auch nicht wirklich, denn der Profi kann das Wesentliche vom Unwesentlichen trennen und lässt alles Unwesentliche weg.) Die Software-Experten, seien sie aus Indien oder Gummersbach, ersatzweise Walldorf, verhalten sich so. Ihr Expertentum ist bloßer Spezialismus. Sie beherrschen eine Sache oder ein Stück eines Systems perfekt, sonst nichts. Damit kann man klotzig Geld verdienen, und an der Höhe ihres Gehalts ermisst die Welt den Wert der geleisteten Arbeit.  Und da ihre firmen-internen oder externen Kunden nichts besseres gewöhnt sind, weil die Ergebnisse – also was da an Programmen so läuft – entsprechend sind, dulden sie es notgedrungen oder kommen, schimpfend zwar, gegen die geballte Inkompetenz nicht an.

 

Zu den o.a. Prinzipien

Es sind 7 - das "Siebengestirn des Software Engineering" -, und selbstverständlich hängen an ihnen eine Anzahl von Konzepten und schließlich Rezepten. Warum also werden diese eher einfachen Prinzipien so schmählich missachtet, so wenig eingesetzt, oder gerade im Gegenteil: auf übertriebene Weise, also grob fehleingeschätzt? Lässt man die diversen Manager beiseite, denn sie leben vom Sekundärwissen, so ist die Frage leicht zu beantworten: Die einen, die Praktiker, haben sie nicht verstanden und scheuen vermeintliche Mühe, und die Theoretiker haben sie falsch verstanden, will sagen: überhöht und bloß formal, denn sie sehnen sich nach formaler Strenge, ja mehr noch: sie finden mehr Freude daran, nach allen Regeln ihrer „Kunst“ zu agieren als solides Handwerk zu betreiben, insbesondere wenn sie damit anderen imponieren können: Wichtigtum ist aller Verirrung Anfang. Nach den späteren Ergebnissen, dem Softwareprodukt und der Projekt-Produktivität, fragen sie selten. Auch wird ein Projekt manchmal – sogar „häufig“, sagt man – gar nicht fertig, sondern nach übermäßigen Anstrengungen als nutzlos abgebrochen, wie es das Nachrichten-Beispiel (s.o.) so treffend bestätigt: Wenn der Frosch in die Magermilch fällt, kann er noch so lange strampeln, sie wird nicht zu Butter.

 

Resümee

Damit dieser Erscheinung begegnet werden kann, müssten gerade nur die o.a. Prinzipien in einer Form angewendet werden, die den Bedürfnissen gutwilliger Softwareingenieure entspricht, ohne sie weder zu überfordern noch zu langweilen. Qualität, sowohl aus Sicht der Anwender als auch der Entwickler, müsste vereinigt werden mit guter Produktivität während der Entwicklung. Das würde der Softwarekrise dann tatsächlich den Garaus machen.

 

PS: „Es gar aus machen“: das Licht in der Kneipe auslöschen, denn es ist Sperrstunde – daher kommt der spöttisch gemeinte „Garaus“, nicht etwa den Gar – denn was wäre ein Gar? – ausmachen. Aber das nur nebenbei.

(Aber das steht auf einigen anderen Blättern: PQ2Checkup)

 

 
Senden Sie E-Mail mit Fragen oder Kommentaren zu dieser Website an:
Stand: 02. September 2009