{"id":261948,"date":"2022-01-30T00:10:00","date_gmt":"2022-01-29T23:10:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=261948"},"modified":"2024-02-19T07:51:03","modified_gmt":"2024-02-19T06:51:03","slug":"60-jahre-software-entwicklung-ein-alptraum-der-mit-grottiger-qualitt-und-im-chaos-endet","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/01\/30\/60-jahre-software-entwicklung-ein-alptraum-der-mit-grottiger-qualitt-und-im-chaos-endet\/","title":{"rendered":"60 Jahre Software-Entwicklung: Ein Alptraum, der mit grottiger Qualität und im Chaos endet"},"content":{"rendered":"

\"StopHeute m\u00f6chte ich mal einen Blick auf das Thema Software-Qualit\u00e4t werfen. Seit \u00fcber 60 Jahren wird Software entwickelt. In den Anfangstagen scheiterten die Entwickler oft an den notwendigen Ressourcen, die die Hardware bot. Heute haben wir unendlich viel Rechenpower, was aber durch grottige Software zunichte gemacht wird. Es wird st\u00e4ndig leistungsf\u00e4higere Hardware bereitgestellt, aber das Software-Zeugs l\u00e4uft immer z\u00e4her. Und die Qualit\u00e4t der Software ist inzwischen (zumindest von mir gef\u00fchlt) unterirdisch. Warum ist das so? Ein paar Gedanken und Informationen.<\/p>\n

<\/p>\n

\"\"Ich selbst bin ja nun noch keine 60 Jahre im Gesch\u00e4ft, meine ersten kleinen Programme entstanden so ab 1977. Und 1993 habe ich den Job als Software-Entwickler und Leiter einer Software-Entwicklungsgruppe an den Nagel geh\u00e4ngt. B\u00fccher zu Visual Basic oder C# wurden lediglich als Finger\u00fcbung und Referenz geschrieben<\/a>. Aber ich schaue mir als Blogger schon an, was heute von Entwicklern auf den Markt kommt und bleibe gelegentlich fassungslos zur\u00fcck. Massenhafte Bugs und Ressourcen-fressende Software aller Orten. Die Tage bin ich auf Twitter \u00fcber nachfolgenden Tweet<\/a> gestolpert, der das Thema \"Ressourcen-fressende\" Software auf den Punkt bringt.<\/p>\n

\"Doom<\/a><\/p>\n

Wir haben Computer mit 16-Kern-CPUs, die mit 3 GHz laufen, und trotzdem nicht in 0,2 Nanosekunden booten. Das zeige, so SwiftOnSecurity, was die Software-Entwickler verkackt haben. Denn auf einem Mikroprozessor f\u00fcr einen Schwangerschaftstest hat es jemand geschafft, das Spiel Doom<\/a> zum Laufen zu bringen. SwiftOnSecurity meint dazu: Im Jahr 2022 l\u00e4uft VisiCalc auf einem Schwangerschaftstest, aber auf Computern im B\u00fcro startest Du Microsoft Excel, und der Kaffee ist schon kalt, bevor dieses B\u00fcroprogramm arbeitsbereit ist. Die Software-Entwickler haben es verkackt – O-Ton:<\/p>\n

Wir haben den Programmierern alles gegeben, doch wir bekommen so gut wie nichts. Siliziumwunder der Metallurgie werden an den Felsen ihrer Gro\u00dfz\u00fcgigkeit zerschmettert. Ein Programmierer zu sein bedeutet, den Diebstahl menschlicher Tr\u00e4ume auf dem Altar der Zeit zu vollziehen.<\/p>\n

In einer einzigen Bewegung spucken uns die Programmierer ins Gesicht und bet\u00f6ren uns mit einer weiteren Wegwerf-Farce ihres Handwerks, die mit einem weiteren Flo\u00df aus Blei in den Ozean endet.<\/p>\n

Ich w\u00fcrde weinen, aber ein Programmierer w\u00fcrde sicher einen Weg finden, die Zeit zu verschwenden, die meine Tr\u00e4nen brauchen, obwohl er in diesen Momenten mehr Rechenleistung hat als in den ganzen Jahrzehnten zuvor.<\/p><\/blockquote>\n

Das ist jetzt eine bitterb\u00f6se Replik auf das, was Software-Entwickler den Anwendern landauf, landab vor die F\u00fc\u00dfe kippen – und in einigen F\u00e4llen ist es noch gesch\u00f6nt.<\/p>\n

Warum Software-Qualit\u00e4t so grottig ist<\/h2>\n

Es ist fast schon ein Jahr her, dass ich bei den Kollegen von Golem auf einen Artikel Warum es so viel schlechte Software auf der Welt gibt<\/a> des Softwareentwicklers und Bloggers Rajiv Prabhakar gesto\u00dfen bin (der englische Artikel ist hier zu finden<\/a>). Der Autor wirft die Frage auf, warum wir so grottige Software-Qualit\u00e4t bekommen, und argumentiert, dass eine solche Inkompetenz in anderen Ingenieurdisziplinen niemals geduldet w\u00fcrde. Mit mehr Excellenz w\u00fcrden auch die Software-Produkte besser, so seine Schlussfolgerung, die ich aus dem Artikel herausgelesen habe.<\/p>\n

\"Kompetenzschema
\nKompetenzschema in der Software-Entwicklung, Quelle: Rajiv Prabhakar<\/p>\n

Eine Br\u00fccke, die so fehleranf\u00e4llig wie ein durchschnittliches Software-System w\u00e4re, w\u00fcrde niemals zum Betrieb freigegeben werden. Die Theorie dieses Autors: Es gibt zu viele Entwickler, die faktisch inkompetent sind, und genau so ist die Qualit\u00e4t der Produkte. Da ich sowohl eine Ausbildung als Ingenieur habe, als auch eine Menge Zeit in Informatik-Vorlesungen investiert habe, kann ich das nachvollziehen und unterschreiben.<\/p>\n

In meinem Studium habe ich h\u00e4ufig Festigkeitsberechnungen von Maschinenelementen (und auch Br\u00fccken) durchf\u00fchren m\u00fcssen. Da gab es sehr fest gef\u00fcgte Regeln, was geht und was nicht. Ein Statiker oder Bauingenieur muss sich an viele Regeln halten und versteht i.d.R. etwas von einem Gesch\u00e4ft. Als Pr\u00fcfstatiker kommen nur die Besten zum Einsatz – in vielen Ingenieursdisziplinen ist dies \u00e4hnlich.<\/p>\n

Ganz anders ist das im Bereich Software-Entwicklung. Die gesamte Branche ist gepr\u00e4gt von der US-Kultur, die keine berufliche Ausbildung, wie im deutschen Handwerk oder im Ingenieurbereich kennt. Da ich beruflich \u00fcber ein Jahrzehnt in der Industrie an der Schnittstelle zwischen Ingenieuren und Informatikern t\u00e4tig war, sind mir auch die Unterschiede in der Denkweise aufgefallen.<\/p>\n

Die Ingenieure hielten sich streng an Regeln, Normen und an das, was auf ihrem Gebiet als Stand der Technik definiert war. Die Informatiker konnten zwar – wenn sie was taugten – in Algorithmen denken und beherrschten die jeweiligen Software-Entwicklungsumgebungen. Aber es gab – bis auf wenige Ausnahmen – keinen Plan, wie die Welt da drau\u00dfen, die durch Software abgebildet werden sollte, so tickt. Entsprechend h\u00e4ufig wurden IT-Projekte an die Wand gefahren. Der Glaube: Wir brauchen nur ein geeignetes Tool und gen\u00fcgend Zeit und Geld, dann wird das schon, lie\u00df Projekte regelm\u00e4\u00dfig gegen die Wand fahren – oft auch, weil die Prozesse, die eigentlich durch die Software abgebildet oder die Anforderungen der Nutzer, die abgedeckt werden mussten, nicht verstanden wurden.<\/p>\n

Interessant ist auch der zweite Artikel Wenn testgetriebene Entwicklung einfach nicht gut genug ist<\/a> von Rajiv Prabhakar, der eine weitere Schwachstelle der Software-Entwicklung in Richtung Qualit\u00e4tssicherung aufdeckt. Wenn ich mich jetzt zur\u00fccklehne, und die Situation im Jahr 2022 betrachte, kommt nur ein Schluss: Es ist nichts besser geworden. Die Informatik liefert scheinbar zwar Ans\u00e4tze wie agile Programmierung, die alles besser machen soll. Aber die Situation ist imho schlimmer als besser geworden.<\/p>\n

Das wird leider nicht besser<\/h2>\n

Jetzt k\u00f6nnte man, auf Basis der obigen Erkenntnis, argumentieren: Wir brauchen nur Exzellenz bei der Software-Entwicklung in den Firmen, schon wird es. Leider geht die Entwicklung bzw. der Trend genau in die andere Richtung. Bei der Recherche zu diesem Blog-Beitrag ist mit noch ein Artikel von Golem unter die Augen gekommen. Unter dem Titel Wir d\u00fcrfen nicht in Sch\u00f6nheit und Perfektion untergehen!<\/a> argumentiert der CTO von Weclap, dass man smarte Software brauen k\u00f6nnte, die ein menschliches Eingreifen in der n\u00e4chsten ERP-Generation reduziert. Den deutschen Perfektionismus h\u00e4lt der CTO, Ertan \u00d6zdil, f\u00fcr gef\u00e4hrlich. Ertan \u00d6zdil ist Gr\u00fcnder und CTO der cloudbasierten Enterprise Ressource Planning (ERP)-Plattform Weclapp<\/a>. Ein zweites Interview<\/a> mit einem weiteren Experten sieht ebenfalls \"Low-Code\" im Kommen und der typische Entwickler sei halt kein Experte.<\/p>\n

Und es gibt noch einen Fundsplitter, der schon l\u00e4nger bei mir im Postfach schlummert und wunderbar passt. Bereits im Juni 2021 ist mir eine Prognose von Gartner auf den Tisch geflattert: Bis 2024 werden Fachleute au\u00dferhalb der IT den Gro\u00dfteil der Technologieprodukte und -dienstleistungen entwickeln.<\/em> Hier die Kernaussagen:<\/p>\n