60 Jahre Software-Entwicklung: Ein Alptraum, der mit grottiger Qualität und im Chaos endet

Stop - PixabayHeute möchte ich mal einen Blick auf das Thema Software-Qualität werfen. Seit über 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ändig leistungsfähigere Hardware bereitgestellt, aber das Software-Zeugs läuft immer zäher. Und die Qualität der Software ist inzwischen (zumindest von mir gefühlt) unterirdisch. Warum ist das so? Ein paar Gedanken und Informationen.


Anzeige

Ich selbst bin ja nun noch keine 60 Jahre im Geschäft, 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ängt. Bücher zu Visual Basic oder C# wurden lediglich als Fingerübung und Referenz geschrieben. Aber ich schaue mir als Blogger schon an, was heute von Entwicklern auf den Markt kommt und bleibe gelegentlich fassungslos zurück. Massenhafte Bugs und Ressourcen-fressende Software aller Orten. Die Tage bin ich auf Twitter über nachfolgenden Tweet gestolpert, der das Thema "Ressourcen-fressende" Software auf den Punkt bringt.

Doom läuft auf einem Schwangerschaftstest

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ür einen Schwangerschaftstest hat es jemand geschafft, das Spiel Doom zum Laufen zu bringen. SwiftOnSecurity meint dazu: Im Jahr 2022 läuft VisiCalc auf einem Schwangerschaftstest, aber auf Computern im Büro startest Du Microsoft Excel, und der Kaffee ist schon kalt, bevor dieses Büroprogramm arbeitsbereit ist. Die Software-Entwickler haben es verkackt – O-Ton:

Wir haben den Programmierern alles gegeben, doch wir bekommen so gut wie nichts. Siliziumwunder der Metallurgie werden an den Felsen ihrer Großzügigkeit zerschmettert. Ein Programmierer zu sein bedeutet, den Diebstahl menschlicher Träume auf dem Altar der Zeit zu vollziehen.

In einer einzigen Bewegung spucken uns die Programmierer ins Gesicht und betören uns mit einer weiteren Wegwerf-Farce ihres Handwerks, die mit einem weiteren Floß aus Blei in den Ozean endet.

Ich würde weinen, aber ein Programmierer würde sicher einen Weg finden, die Zeit zu verschwenden, die meine Tränen brauchen, obwohl er in diesen Momenten mehr Rechenleistung hat als in den ganzen Jahrzehnten zuvor.

Das ist jetzt eine bitterböse Replik auf das, was Software-Entwickler den Anwendern landauf, landab vor die Füße kippen – und in einigen Fällen ist es noch geschönt.

Warum Software-Qualität so grottig ist

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 des Softwareentwicklers und Bloggers Rajiv Prabhakar gestoßen bin (der englische Artikel ist hier zu finden). Der Autor wirft die Frage auf, warum wir so grottige Software-Qualität bekommen, und argumentiert, dass eine solche Inkompetenz in anderen Ingenieurdisziplinen niemals geduldet würde. Mit mehr Excellenz würden auch die Software-Produkte besser, so seine Schlussfolgerung, die ich aus dem Artikel herausgelesen habe.

Kompetenzschema in der Software-Entwicklung
Kompetenzschema in der Software-Entwicklung, Quelle: Rajiv Prabhakar

Eine Brücke, die so fehleranfällig wie ein durchschnittliches Software-System wäre, würde niemals zum Betrieb freigegeben werden. Die Theorie dieses Autors: Es gibt zu viele Entwickler, die faktisch inkompetent sind, und genau so ist die Qualität 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.

In meinem Studium habe ich häufig Festigkeitsberechnungen von Maschinenelementen (und auch Brücken) durchführen müssen. Da gab es sehr fest gefügte 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äft. Als Prüfstatiker kommen nur die Besten zum Einsatz – in vielen Ingenieursdisziplinen ist dies ähnlich.


Anzeige

Ganz anders ist das im Bereich Software-Entwicklung. Die gesamte Branche ist geprägt von der US-Kultur, die keine berufliche Ausbildung, wie im deutschen Handwerk oder im Ingenieurbereich kennt. Da ich beruflich über ein Jahrzehnt in der Industrie an der Schnittstelle zwischen Ingenieuren und Informatikern tätig war, sind mir auch die Unterschiede in der Denkweise aufgefallen.

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ßen, die durch Software abgebildet werden sollte, so tickt. Entsprechend häufig wurden IT-Projekte an die Wand gefahren. Der Glaube: Wir brauchen nur ein geeignetes Tool und genügend Zeit und Geld, dann wird das schon, ließ Projekte regelmäßig 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.

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

Das wird leider nicht besser

Jetzt könnte 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ürfen nicht in Schönheit und Perfektion untergehen! argumentiert der CTO von Weclap, dass man smarte Software brauen könnte, die ein menschliches Eingreifen in der nächsten ERP-Generation reduziert. Den deutschen Perfektionismus hält der CTO, Ertan Özdil, für gefährlich. Ertan Özdil ist Gründer und CTO der cloudbasierten Enterprise Ressource Planning (ERP)-Plattform Weclapp. Ein zweites Interview mit einem weiteren Experten sieht ebenfalls "Low-Code" im Kommen und der typische Entwickler sei halt kein Experte.

Und es gibt noch einen Fundsplitter, der schon länger 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ßerhalb der IT den Großteil der Technologieprodukte und -dienstleistungen entwickeln. Hier die Kernaussagen:

  • Bis 2024 werden laut des Research- und Beratungsunternehmens Gartner 80 % der Technologieprodukte und -services von Personen entwickelt werden, die keine Technologieexperten sind.
  • Dieser Trend wird von einer neuen Käuferkategorie außerhalb der traditionellen IT-Organisation angetrieben, die einen größeren Anteil des gesamten IT-Marktes einnimmt. Heute betragen die geschäftsorientierten IT-Ausgaben im Durchschnitt bis zu 36 % des gesamten offiziellen IT-Budgets.

Dazu gibt es dann noch folgendes Statement von Rajesh Kandaswamy, Distinguished Research Vice President bei Gartner: Das digitale Business wird von CEOs als Teamsport betrieben und ist nicht mehr die exklusive Domäne der IT-Abteilung. Das Wachstum digitaler Daten, der Low-Code-Entwicklungstools und der durch künstliche Intelligenz (KI) unterstützten Entwicklung gehören zu den vielen Faktoren, die eine Demokratisierung der Technologieentwicklung über IT-Experten hinaus ermöglichen. Mehr Informationen finden sich in dieser Pressemitteilung.

Also eine Entwicklung, die genau konträr zu dem läuft, was ich weiter oben etwas herausgearbeitet habe: Wir bräuchten eigentlich Menschenverstand und mehr Exzellenz in der Software-Entwicklung, wenn wir die Qualität haben wollen. Stattdessen sollen Personen die künftigen Software-Systeme und Lösungen entwickeln, die keine Technologie-Experten sind. Ein Toolchen, etwas Klicki-Bunti, darüber eine PowerPoint-Folie gelegt und ein Generator macht daraus eine Universal-App, die jeden Anwender blass werden lässt. Wobei blass manchmal die falsche Umschreibung ist, manche bekommen hochrote Köpfe vor Zorn, wenn nichts funktioniert und werden erst blass, wenn Schwachstellen und Fehlfunktionen echt weh tun und zu finanziellen Konsequenzen führen.

Ich kann zwar nachvollziehen, dass die Leute auf die Schnelle ihre Lösungen selbst stricken wollen – ist schließlich ganz einfach, und man weiß ja, was man will. Aber das sind in meinen Augen keine guten Voraussetzungen für die Qualität zukünftiger Software-Systeme und mir wird Angst und Bange ob dieser Entwicklung. Die Büchse der Pandora ist geöffnet. Schaut man sich das Ganze an, befürchte ich dystopische Verhältnisse.

Ich würde sogar so weit gehen, und behaupten, die Informatik und Software-Entwicklung hat uns in die größte Krise des 21. Jahrhunderts geführt. Kein Tag, an dem wir nicht über fette Bugs, gravierende Schwachstellen oder Sicherheitsvorfälle reden müssen.

Stellen wir uns vor, das wird eine Brücke gebaut, und keiner weiß, ob die nicht schon vor der Inbetriebnahme einstürzt – so in der Art "Och, wir fangen an und schauen mal, was bei herauskommt". Da würde jeder abwinken, keine Chance, so ein Projekt durchzukriegen. In der Software-Entwicklung gilt dagegen so etwas irgendwie als Königsweg. Das kann auf Dauer nicht gut gehen. Oder sehe ich das alles wieder einmal zu schwarz?

Ähnliche Artikel
Dave Cutler: 50 Jahre Einsatz für Software-Qualität
Gehärteter Online-Banking-Browser S-Protect, ein Totalausfall?
Software: Unser Grab als PKW-Besitzer der Zukunft?


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Software abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

36 Antworten zu 60 Jahre Software-Entwicklung: Ein Alptraum, der mit grottiger Qualität und im Chaos endet

  1. Ralf S. sagt:

    "Oder sehe ich das alles wieder einmal zu schwarz?"

    Keineswegs! Meine vollste Zustimmung zu diesem Artikel. Ich vergleiche Software immer ganz gerne mit z. B. einem neuen Auto, das man sich kauft. Die wenigsten Käufer würden es wohl bei einem Kfz akzeptieren, dass man ständig in die Werkstatt damit muss und sogar u. U. damit öfters auch mal komplett liegen bleibt. Spätestens nach der dritten Nachbesserung würde ich es dem Händler wieder auf den Hof stellen und hätte gerne mein Geld zurück. Nur bei Software scheinen wir alle doch sehr schmerzbefreit, oder auch kleine Masochisten zu sein … ;-) Mal von den gesellschaftlichen, betriebs- und volkswirtschaftlichen Schäden ganz abgesehen, die sich ja bei Weitem noch wesentlich negativer auswirken als "nur" der relativ kleine, private Schaden und Ärger.

    • Singlethreaded sagt:

      Und das Ganze bringt noch das Folgeproblem mit, dass Updates häufig nicht auf den Geräten ankommen. Sei es, weil das Gerät nie konzipiert wurde Updates zu erhalten (Billiggeräte), dem Nutzer gar nicht bewusst ist, dass man Updates installieren sollte (Unwissenheit), es dem Nutzer einfach egal ist (Ignoranz), der Hersteller den Support mal wieder viel zu früh eingestellt hat (Obsoleszenz) oder der Nutzer mit Problemen rechnet (Realist).

      In der Konsequenz bin ich dann wieder bei Günter, dass dieser Zustand irgendwann zum großen Knall führen wird.
      Interessanterweise werden die Gefahren von IT-Geräten und ihrer Software, warum auch immer, meist hingenommen. Ein Auto mit defekten Bremsen würde aber niemals durch dem TÜV kommen.

      Am besten wäre es natürlich, wenn man gar keine Updates brauchen würde. Das dürfte aber ein Wunschtraum bleiben, da unsere Welt nicht statisch ist und sich Anforderungen und Standards mit der Zeit entwickeln.
      Daher braucht es dringend einen Plan wie IT-Geräte sicher betrieben werden können und auch wie ein Schaden Dritter durch diese Geräte minimiert bzw. verhindert werden kann.

      Ich hatte gerade erst wieder gelesen, dass Microsofts Azure Cloud einem DDOS-Angriff ausgesetzt war, welcher mit über 3 Terrabit Bandbreite erfolgte. Quelle war wohl ein Botnetz aus IoT-Geräten. Das zeigt, dass fast alles am Netz als Waffe mißbraucht werden kann, wenn es unzureichend gesichert ist.

      Gruß Singlethreaded

      • Olli sagt:

        Ein Bauingenieur haftet 30 Jahre lang für seine Statik. Und eben jene 30 Jahre fordere ich schon länger für Hardware und Software.

        Kein Mozilla Entwickler wäre jemals auf die dumme Idee gekommen alle paar Wochen ein Major Release auf den Markt zu bringen, wenn er für jedes einzelne davon 30 Jahre lang Support liefern müsste…

        • Heinz sagt:

          Als Entwickler haftet man unter Umständen schon jetzt 30 Jahre lang. Werfen Sie einmal einen Blick in die Verjährungsfristen des BGB. Es denkt nur kaum ein Entwickler daran.

      • chw9999 sagt:

        Updates? XKCD hat das was:
        h**ps://www.explainxkcd.com/wiki/index.php/2224:_Software_Updates

  2. janil sagt:

    "Oder sehe ich das alles wieder einmal zu schwarz?"

    Nein, die vielen Hackerangriffe auf alles und jeden sind doch nur durch unsaubere Programmierung und mangelnde Qualitätssicherung erst in diesem momentanen und sicher noch zunehmendem Ausmaß möglich geworden.

  3. Ekkehard sagt:

    Und das ganze ging schon vor 30 Jahren los. Da war Moores Gesetz bereits akzeptiert und hat sich von Jahr zu Jahr bestätigt, und an der Uni haben sie uns erzählt, daß es nicht kosteneffizient ist, Zeit in die Entwicklung laufzeitoptimierter und speichersparender Algorithmen zu stecken, weil die schlechte Leistung der ersten einigermaßen funktionierenden Lösung in kurzer Zeit durch die bessere Hardware ausgeglichen wird. Davon bekommt man dann (vor 10 Jahren) Maustreiber mit Dutzenden Megabyte, deren Funktionalität mit wenigen Kilobyte abgebildet werden könnte. Für diese wenigen Kilobyte wäre auch eine ordentliche Qualitätssicherung möglich, für die aktuellen Monsterprogramme mit undurchsichtigen Algorithmen und hunderten von Monster-Bibliotheken aber schon lange nicht mehr :-(

  4. Luzifer sagt:

    naja das liegt einfach daran das es bei Software keine Produkthaftung gibt … würde es die geben sähe alles anders aus, den dann wären sowohl Apple, wie auch Microsoft und so gut wie alle großen Softwarefirmen pleite durch die ganzen Schadensersatzansprüche.

    Es gibt nur sehr sehr wenige andere Branchen dies sich so etwas leisten können … Banken zum Beispiel, die werden notfalls durch den Staat gestützt. Die Autoindustrie siehe Diesel Gate.

    Die meisten anderen Branchen würden jedoch solche Schlampereien nicht überleben.

    60 Jahre Programmierung? Da klammert man aber einiges aus: die ersten Lochkarten Programmierungen kommen aus dem 18 Jh. wenngleich das kaum Computer waren … aber selbst Computer mit Lochkarten als Programme sind älter! Mein Vater programmierte noch 1950 mit Lochkarten bis so ca. 1970. Diese Computer waren allerdings kaum für den Heimgebrauch zu gebrauchen ;-P "Hallengroße Schränke"

  5. ThBock sagt:

    Da kommt ja noch dazu, was alles im Hintergrund rödelt.
    Telemetrie, Antivirenprogramme usw. usf.
    Man muss sich nur mal ansehen, was uBlock so alles abfängt.
    Neulich habe ich mal 'ne Liste gesehen, mit über 900 Facebook Servern.
    Wenn man seine Daten in der ganzen Welt verteilt, belastet das natürlich zusätzlich die Ressourcen.

  6. Andy sagt:

    Ich komme selbst eigentlich aus der Systemprogrammierung, das vorweg. Und mir graut es auch täglich bei der Software, die wir so einsetzen (müssen). Aber ich komme zu anderen Ergebnissen, was die Notwendigkeiten in der Software-Entwicklung angeht.
    Im Business-Bereich müssten die Basiskomponenten deutlich besser programmiert werden – oder nennen wir es resilienter gestaltet. Darunter zähle ich die Betriebssysteme, die Treiber und – aus meiner Sicht – Workflow-Basis-Systeme, wie auch Low-Code- und No-Code-Systeme.
    Letztere sind ja genau dafür gut, dass die Firma ihre Abläufe effizient digitalisiert bekommt und individuell gestalten kann. Das machen bisher Programm-Monster, die eine Minute zum starten brauchen, alle Bibliotheken dieser Welt einatmen und dann zu 90% Funktionsballast mit sich herumtragen.
    Mein aktueller Stand sind hier 102 Softwaresysteme, die irgendwie zusammengeklöppelt sind und ungefähr zu 10-15% von jedem denkbaren Fehler betroffen sind (siehe log4j).
    Mit 3-4 Systemen, auf denen dann alles abgebildet ist, könnte ich wesentlich besser leben. Wenn diese effizient und resilient programmiert sind. 60% unserer internen Workflows kann ich mit einem Standardablauf abbilden, es ist nur nicht gewollt. Denn Spezialsoftware kaufen ist leichter, als Abläufe analysieren und dann passend umsetzen.
    Also patchen wir dutzenden Spezialsoftware-Systemen hinterher, die eigentlich schon nach dem Prinzip gefrickelt sind. Also auf Basissystemen aufsetzen und halb zusammen geklickt. Nur eben nach dem Prinzip, das möglichst viel Gewinn rausspringen muss.
    Ich sehe also fünf Dinge, die aktuell einen Ansatz für Besserung im Business schaffen könnten:
    – die Pflicht, jeden Datenverarbeitungsablauf vor der Umsetzung zu modellieren und alle möglichen Verarbeitungsdaten, Entscheidungen und Verwendungen zu dokumentieren
    – die Festlegung verbindlicher (Sicherheits-) Standards für Betriebssysteme, gegebenenfalls geförderte Neuentwicklungen
    – die Entwicklung resilienter Basis-Systeme für Business-Abläufe, gegebenenfalls geförderte Neuentwicklungen
    – die zwingende Verwendung im öffentlichen Sektor und regulierten Industrien, wobei dies eine Zertifizierung mitbringen müsste
    – Steuerungssysteme und ähnliches sind als Teil der Industrie-Anlage prüfpflichtig und vollständig Teil der Gefahrenhaftung
    Wenn eine Stelle dann selbst nicht in der Lage ist, kann die ja Abläufe für Basissysteme kaufen oder aus zentralen Reposities laden, die zu pflegen wären (gibt es ja schon, nur schleppend umgesetzt – eine Stiftung wäre hier besser, als "die EU").

    Firmen sollten wie bisher weiter machen dürfen, aber jede Sondersoftware sollte die Gesamtzertifizierung aufheben. Was dann durch eine alternative Zertifizierung für alles nachgeholt werden kann, was aber kenntlich sein muss.
    Dann kann der Handwerker bei Verwendung der Basiskomponenten mit "zertifizierte Basis-Sicherheit" für seine Kunden werben. Der hippe Datenschuppen aber nicht. Der könnte dann mit "alternativ zertifizierte Basis-Sicherheit" oder mit "zu hip für sowas" werben.

    Naja, nur ein paar Gedanken zum morgendlichen Kaffee…

    • Anonymous sagt:

      Sehr gut zusammen gefasst. Das Problem dabei ist aber, das das Business heutzutage viel aus ausprobieren, schnellebigkeit und hoher Komplexität besteht. Man hat/nimmt sich einfach nicht mehr die Zeit erstmal zu analysieren was man wirklich braucht oder einen Nutzen hat. Es wird schell drauf los probiert, mit genauso geschriebener Software losgearbeitet. Wenn der Versuch nicht gelingt, ist der Verlust überschaubar, was der Vorteil daran ist. Wenn er glückt, hat man aber plötzlich ein beschissen programmiertes Kernsystem. Und da fängt der Fehler an. In dem Moment müsste der schlaue Manger in refactoring oder neu Programmierung (zumindest des Kerns) investieren. Aber läuft doch, lieber der nächsten Idee hinterher jagen…

  7. Ärgere das Böse! sagt:

    Intel hat vor ein paar Jahren etwas Ähnliches geagt.
    Sinngemäss: Den Geschwindigkeits-Zuwachs, den wir mit schnelleren Prozessoren erreichen, wird durch immer schlechtere Programmierer zunichte gemacht. Es gibt niemanden mehr, der schlanke Programme schreiben kann.

  8. Roger Wilco sagt:

    Die Leute haben sich dran gewöhnt. Dass man nach jedem 2. Klick erstmal auf die Eieruhr wartet und nach jedem 20. mal eine nichtssagende Fehlermeldung wegklicken muss ist oft schon völlig normal.

    Ich bin selbst Softwareentwickler für Windows und weiß um mehr als genug Stellen bei uns die schlecht optimiert sind und einfach zu lange dauern. Ich habe leider aber auch nur begrenzt Zeit, etwas fertigzustellen und wenn einmal bunte Pixel auf dem Bildschirm waren, dann ist oft relativ wenig Verständnis da, weshalb man da noch "hinter den Kulissen" aufräumen müsse.

    Aber die Performance ist ja auch nur eine der angesprochenen Dinge – Insgesamt ist es einfach die Qualität und Verlässlichkeit, die grade bei Microsoft Windows in letzter Zeit so gelitten hat. Es ist nichts das man messen kann, im Gegensatz zu einer Belastungsgrenze einer Brücke oder MTBF einer Hardware-Komponente. In was sollte man es messen? Ärgernisse pro Minute?

  9. Sven Fischer sagt:

    Seeeeeeeeehr guter Artikel. Sowas sollte in der c't veröffentlicht werden.

  10. 1ST1 sagt:

    Die Situation ist zwei Sachen geschuldet.

    1. Hardware.

    Zu 8-Bit und 16-Bit-Zeiten war die Hardware die Konstante, da nicht aufrüstbar, oder nur unter hohem Aufwand. Zum Beispiel der Commodore 64 wurde von 1983 bis 1994 fast unverändert verkauft. Also wurde 11 Jahre lang neue Software mit neuen Ansprüchen auf immer der selben Hardware veröffentlicht – und selbst heute holen Enthusiasten aus dieser Hardware noch erstaunliche Effekte raus. Um performancemäßig mit der Anwendung mithalten zu können, wurden (und werden da heute noch!) zeitkritische Routinen in Assembler per Hand optimiert. Ähnliche Situation auch noch beim Commodore Amiga, Atari ST und ähnlichen Systemen, auch bei den frühen IBM XT Kompatiblen.

    Erst in den 1990ern änderte sich das, als die Commodore, Atari usw, bei den Anforderungen bei modernen Anwendungen und Spielen performancemäßig nicht mehr mithalten konnten. Wurde der PC für eine Anwendung zu langsam, so wurde er aufgerüstet, schnelleres Mainboard, schnellere CPU, mehr Speicher oder gleich ein modernerer PC der ganz selbstverständlich auch noch die alten Anwendungen ausführen konnte. Die Notwendigkeit von handoptimiertem (Assembler-)Code verschwand: zu langsam? Hardware aufrüsten! Zack, geht. Es gab Zeiten, da wurde für 33 MHz mehr CPU-Takt alle paar Monate die CPU oder auch gleich das Mainboard ausgewechselt, selbes gillt für Grafikkarten. Die Performance der neuen Hardware steigt ja konstant, bis heute. Und da nicht mehr hardwarenah programmiert wird, sondern alles über Bibliotheken, Treiber, Middleware wie DirectX, OpenGL, DirectSound usw. klappte das mit dem Aufrüsten auch.

    2. Software.

    Damals musste man die Software noch selbst in allen Details selber entwickeln, fehlende Routinen programmierte man selbst, dann fing das mit Libraries an, die einem erstmal Systemaufrufe bestimmter Betriebssystene oder direkte Hardwareprogrammierung über einfacher zu verstehende Funktionen abnahmen, man musste nur die passende Lib einbinden, fertig. Der Anwender installiert den Hardwaretreiber für eine komplett neue Grafikkarte, und schon kann das Programm die neuen Grafikauflösungen direkt nutzen, eine Disziplin die z.B. auf dem Amiga oder Atari ST noch sehr schwer war, "auflösungsunabhängig programmieren"… Über die heute überall verfügbaren Hardwaretreiber, Bibliotheken, Middleware mit all ihren Abhängigkeiten ist Software, die früher Mannjahre Entwicklung gekostet hätte, mit wenigen Klicks zusammenstöpselbar. Letztlich wissen heutige Softwareentwickler garnicht mehr , was sie sich da z.B. npn so alles einbinden, was sie mit in ihr Programm reinkompilieren, obwohl die jeweiligen Funktionsaufrufe teils garnicht gebraucht werden. Das Resultat ist verfettete Software, wo man nicht mehr jede Programmzeile oder gar jede eingebundene Bibliothek kennt, was dann auch zu so Effekten wie neulich mit log4j, colors.js und faker.js führt. Bei uns war es z.B. bei log4j so, dass die Hersteller der Software teils anfangs nicht mal sagen konnte, ob die von uns in deren Software gefundenen log4j-Dateien in Verwendung sind. Oder wer weiß schon genau, wieviele Tomcat-Webserver Server im eigenen Firmen-Netzwerk so mitlaufen und wieviele davon sicherheitstechnisch noch problemlos sind? Aber dafür ist mal eben Ruckizucki eine KI-Funktion in dem Programm drin, ohne dass man verstehen muss wie Neuronale Netze funktionieren.

    Heute sind wir allerdings in der komfortablen Situation, dass für für viele Anwendungen selbst 10 Jahre alte Hardware eigentlich schnell genug ist, aus Perfomance-Gründen müssen am Desktop eigentlich nur noch Hardcore-Gamer (und Bitcoin-Miner) aufrüsten (und alle die Win 11 mit Updategarantie benutzen wollen).

    • 1ST1 sagt:

      Noch ein Nachtrag: Wenn erstmal die Quantencomputer im Mainstream ankommen, sprich zB. als Rechenbeschleuniger als PCIe-Steckkarte nachrüstbar werden, wird die Sache noch undurchsichtiger. Als jemand, der einen Volladdiere noch zum Verstehen in TTL selbst aufgebaut hat, ist diese Technik wie Voodoo. Sehr vereinfacht ausgedrückt soll ja ein Quantencomputer erstmal als Ergebnis einer Rechenoperation erstmal "alle denkbaren" Ergebnisse (blitzschnell) errechnen und entscheidet dann im zweiten Schritt, welches dieser Ergebnisse tatsächlich richtig ist. Wer will da die Richtigkeit von Programmcode überhaupt noch prüfen können? Für mich als Quantencomputer-Laien liegt das völlig im Dunkeln. Wird ja schon bei "KI" schwierig.

      • mw sagt:

        "wird ja schon bei KI schwierig". Zunächst mal ist das meiste, was hier als KI bezeichnet wird gar keine Ai sondern meist nur Statistik. Das Problem beim maschinellen Lernen sind die Lerndatensätze. Und hast Du im Nachhinein einen solchen als schlecht ermittelt, Pech gehabt. Einzelne Lerndatensätze lassen sich nicht rückgänig machen. Auch kann das Ergebnis nicht nachvollzogen werden in Form einer verifizierbaren Kette von Entscheidungen. KI trifft sozusagen Gott gegebene Entscheidungen. Nachprüfung ist Fehlanzeige. Wer als Programmierer etwas von KI schwurbelt, bekommt bei mir keinen Job. Nicht mal die Werkstatt fegen.

  11. U get what u paid for sagt:

    Qualität kostet Zeit und Geld – aber kaum jemand ist bereit beides aufzuwenden. In der Folge produzieren Frameworkopfer mithilfe von Copypaste innerhalb ihrer Effizienzfallen Softwarefragmente, deren Funktionieren streng genommen eine Frage zufälligen Geschehens ist.

  12. Thierry sagt:

    Ich sehe das nicht so negativ, denn bei der Komplexität eine Anwendung am Laufen zu bekommen, sind Fehler in der Programmierung unvermeidlich. Als Beispiel nehme ich die Zeilen eines Lesebuches, die meisten sehr weit unter 100 Millionen stehen. Wenn ich diese unter die Lupe nehme, werde ich immer Fehler finden. Die Frage ist: Wie grob darf ein Fehler sein, bis dieser mir an die Weiterlesung des Buches hindert? In Rechnersprache umgesetzt: Wie störanfällig darf eine Anwendung sein, bis diese mir an die gute Weiterführung meiner Arbeit hindert? Und genau dieser Faktor ist wichtig. Ebenfalls beinhaltet diese Störanfälligkeit die Sicherheit der Anwendung während seiner Nutzung. Und solang dieser Faktor niedrig gehalten werden kann, dann darf man froh sein, dass alles bei der Komplexität der IT-Technologie einiger Maßen gut funktioniert. Der Vergleich mit einem Fahrzeug ist hinfällig, denn auch ein Fahrzeug kann störanfällig sein. Und nicht zuletzt gibt es immer zwei Akteure: die Anwendung und der Anwender.

  13. Cestmoi sagt:

    Eindruck aus Gesprächen am Arbeitsplatz und in der Freizeit:
    Neue Hassfigur Nr. 1: Der Informatiker; noch vor Bankern, Rechtsanwälten und Versicherungsvertretern.

  14. Stefan Kanthak sagt:

    AUTSCH: dummerweise begehst Du den Fehler, 'Informatik' und 'Programmieren' in einem Atemzug zu nennen. Weder ist ein Programmierer notwendigerweise ein Informatiker, noch ein Informatiker notwendigerweise ein Programmierer.
    Ein TEILGEBIET der Informatik ist jedoch (seit über 50 Jahren) das 'Software Engineering', also die (wie in anderen/klassischen technischen Disziplinen übliche) ingenieurmässige Konzeption Planung, Erstellung, Verifikation etc. von Software.
    (Ich habe vor 45 Jahren an der TH Darmstadt in einem Forschungsprojekt von Dave Parnas, der beispielsweise in https://en.wikipedia.org/wiki/Software_engineering genannt wird, mitgearbeitet, in dem beginnend mit einer formellen und beweisbar korrekten Spezifikation ein sicheres Betriebssystem für Mainframes ähnlich der /370 erstellt wurde.)
    Dummerweise findet eine solche ingenieurmässige Entwicklung schon seit Jahren bei den üblichen Verbreche(r)n, die Hinz und Kunz vorgesetzt werden, nicht (mehr) statt.
    In der Aeronautik und einigen anderen Anwendungsbereichen (NASA, ESA, …) dagegen, wo Softwarefehler VIEL Geld oder gar (DIREKT) Menschenleben kosten können, waltet typischerweise noch die notwendige Sorgfalt.

  15. Cestmoi sagt:

    Ich will weder beckmessern noch streiten, nur zwei Dinge:

    1.
    Erzähl' das mal den 'Leuten auf der Strasse'. Denen gehen solche 'Feinsinnigkeiten' ab, nicht ganz zu unrecht. Unter 'm Strich geht es darum, dass IT ihre Heilsverprechen nicht einlösen kann, selbst wenn sie technisch funktioniert (Bsp. soziale Medien). Dann ist sie halt gesellschaftlich/zivilisatorisch ein Rückschlag.

    2.
    Betr. "Aeronautik" stellvertretend (!):
    https://www.bloomberg.com/news/articles/2022-01-26/f-35-fighter-jet-s–14-billion-software-upgrade-is-deployed-despite-flaws

  16. Max sagt:

    Mit "Low Code" ist es wie mit Wix und Konsorten: Entweder steht am Ende Qualität oder Grottiges. Hinter "Low Code" verbirgt sich in der Regel die "Copy and paste"-Politik von heute. Man klickt sich irgendetwas zusammen, ohne aber zu wissen, was da im Hintergrund eigentlich abläuft. Du kannst der Jugend heute einen PC, ein Notebok oder Tablet in die Hand geben. Sie können es bedienen, aber verstehen weder den Aufbau noch grob die Funktionsweise. Sie können Dinge anwenden, mehr aber auch nicht. Wehe, dass Ding geht kaputt oder meldet Servicebedarf, dann ist das Geschrei ganz schnell groß.

    Was mir bezüglich Softwareentwicklung aufgefallen ist: Die Unternehmen, die ihre Softwareprodukte intern einsetzen, haben nicht selten schlechte Prozesse. Das heißt: Die schlechte Softwarequalität ist das Spiegelbild der internen Prozesse, die womöglich noch schlechter sind, würde man genauer hinsehen. Das erkennt man beispielsweise bei vielen ERP-Systemen: komplizierte Benutzeroberflächen mit verschachtelten Menüs, altbackenes Design, veraltete Technologien, hoher Ressourcenbedarf bei gleichzeitig hoher Ressourcenverschwendung und Ladezeiten jenseits der Akzeptanz. Und da reden wir noch nicht mal über teil- oder vollautomatisierte Teilprozesse, Schnittstellen und so weiter.

    Dabei wusste schon Albert Einstein: "Dinge sollten so einfach wie möglich sein, aber nicht einfacher".

  17. oli sagt:

    Sry Hr. Born, aber mit den Artikel sind Sie gut 10 jahre zu spät dran. Fefe rantet da auch schon seit mehreren Jahren drüber. Und ich empfehle jedem mal das Retro-Experiment: Neue Software auf alter Hardware, dann merkt man erstmal, wie schlimm es wirklich ist. Denn letztendlich ist es für den Anwender eigt. egal, der will nur "Anwenderdinge" tun, also Textverarbeitung, Tabellekalkulation, Browsen etc. Auf die Spitze hat es aber eindeutig Microsoft mit der ganzen Telemetriesammelei und -Übertragerei getrieben (War das nicht Visual Studio, was irgendwie bloatigen Telemetrie-Code in ein simples "Hello World" Programm schleuste?). Scheint irgendwie jeder schulterzuckend hinzunehmen, dass diese Dinge zusätzliche Rechenoperationen (=weniger Rechenleistung für wesentliche Dinge/mehr Stromverbrauch/weniger Akkuleistung) und IOs auf dem Rechner und sämtlichen Koppelgeräten bis hin zu den MS-Telemetrieservern erzeugt. Als ob elektrische Energie aus der Steckdose irgendwie gottgegeben ist …

  18. mw sagt:

    Ich sehe das ganz genauso. nach mehr als 30 Jahren in der SW Entwicklung als Ingenieur mit Uni Bildung unterwegs muss ich leider sagen, es wird immer schlimmer. Wenn ich an Dinge wie software defined car oder automatisiertes Fahren denke, wird mir schwindelig dabei. Jedes Projekt, das etwas von KI schwurbelt und dann noch Blockchain erwähnt, ist es nicht wert auch nur angeschaut zu werden. Software zu entwickeln, heißt doch zuerst die Prozesse zu verstehen, sowohl die Prozesse, die die Software abbilden und unterstützen soll und auch die Prozesse, die Software überhaupt wirken lassen, also Prozessoren, Compiler, Tools. Schon bei dem allersten Windows gab es den Kalauer "Mal gates und mal nicht" (mal funktiniert es, mal nicht). Das ist heute nicht besser geworden. Ich habe viele Entwickler kennengelernt und jeder schört auf die Software. Nicht jeder auf jede, aber ganz sicher jeder auf seine. Agile, TDD und ähnliche Säue, die durchs Dorf getrieben werden, haben nichts verbessert, eher verschlimmert. Ich gehöre noch zur Generation der Ingenieure, die kreativ sein mussten, weil die HW nicht genug Leistung hatte, die Algorithmen geschlossen zu lösen. Erzähle heute mal was von stückweiser Linearisierung im Arbeitspunkt einem Softwerker und er wird Dich mit großen Kinderaugen anschauen. Es gibt natürlich auch seltene Ausnahmen, wenige in der freien Wirtschaft, viele in den Forschungseinrichtungen z. B. JPL oder CERN.

  19. Matthias Hoppe sagt:

    Wenn man sieht was man z.B. auf einem C64 zum laufen bringen kann bzw. allgemein auf Geräten mit stark beschränkten Ressourcen, kann man erahnen wie weit die Schere auseinander klafft. Nun muss man ehrlicherweise sagen das eine so effiziente Programmierung wie auf besagtem C64 nicht realistisch ist, da tüfteln Leute Monatelang an Lösungen eine MP3 mit den vorhandenen Ressourcen abzuspielen… aber ein bisschen Ehrgeiz und den Willen der Softwareunternehmen etwas effizient und von Grund auf Neu zu erstellen könnte nicht schaden!

  20. Stefan sagt:

    Volle Zustimmung von mir als Ingenieur und Softwareentwickler! Das ist ein sehr trefflich geschriebener Artikel. Nur müsste ein etwas besserer Vergleich als der zu Straßenbrücken gefunden werden. Brücken werden einmal durch-spezifiziert und dann nach definierten Standards gebaut. Wenn die Brücke fertig ist kommt (i.d.R.) niemand mehr und will hier und da noch etwas angebaut haben, die Höhe verändert, die Brücke versetzt oder über ein anderes Tal umgezogen haben etc.

    Die Krux bei Software ist ja die Vielfalt der technischen Ausgestaltung und Feature-Weiterentwicklung, die Abhängigkeit zur unterliegenden Hardware mit deren speziellen Treibern und natürlich Kunden mit immer ganz dringlich Prio-1 Änderungs- und Feature-Wünschen. Dazu haben über die Lebenszeit des Produkts viele verschiedene Entwickler und Kenntnisstände Ihre Hände im sich weiter entwickelnden Produkt, Frameworks und Abhängigkeiten ändern sich etc.

    Es gibt ja durchaus Software in lebenskritischen Bereichen mit gesetzlichen Anforderungen (Medizintechnik/Luftfahrt), wo streng nach ingenieurmäßigen Vorgehen entwickelt wird und von dort vernimmt man ja auch vergleichsweise wenig dieser Probleme. Aber da kann der Kunde auch nicht 'mal noch eben schnell' Featurewunsch X nachschieben oder sorglos Patches reingeschoben werden …

  21. Johannes sagt:

    Rajiv Prabhakar, bei dem Namen werden Erinnerungen an ein Projekt mit einem Entwicklungsteam in Indien wach. Es war ein Clash der Kulturen, deutscher Michel trifft indian feeling. Kreativ, keine Frage, aber es fehlte da an vielem. Da kam schon mal die Frage warum man beim Schreiben von Daten in die Registry Admin Rechte benötige. Die Ursache war einfach, man schrieb die Daten in eine .reg Datei und rief regedit.exe auf. Und das war bei weiten nicht das einzigste Problem. Man muss es aber mal selbsr erlebt haben.

    Das Problem liegt meines Erachtens am Outsourcing. Was macht man die Qualität nicht stimmt? Wenn Fehler über Fehler passieren? Wenn der Ausschuss über einem kritischen Nivau liegt? Wenn z.B. 30% der gelieferten Teile mangelhaft sind? Zurückschicken? Vertrag künden?

    Das europäische Verständnis von Qualität, entspricht nicht dem amerikanischen, chinesischen, japanischen oder indischen.

    • Günter Born sagt:

      Die pragmatische Lösung: Wir müssen amerikanischer oder indischer werden. Das "japanischer" verkneife ich mir – nach Arbeitsaufenthalten in Japanien muss ich mir das nicht mehr geben und werde eher zum Abstinenzler ;-)

  22. Knusper sagt:

    Noch eine Beobachtung: Jeder "normale" Benutzer will Programme sogar kostenlos.
    (aber das ist eine weitere Baustelle)

  23. Flotter Ferdi sagt:

    Das Übel ist der Faktor Zeit. Niemand möchte (und kann) handoptimierten Assemblercode (Achtung Sarkasmus) heute bezahlen. Software muss schnell und verhältnismäßig günstig in der Anschaffung sein. Lizenzfallen und ausufernde TOC werden erst (zu) spät erkannt.

    "Bodenständige Lösungen" werden verlacht und pauschal abgewertet. Keine fanzy UI, Mobile first, läuft ja nicht in der Cloud usw.

    Wie andere schon schrieben, besteht Software heute weitestgehend aus zusammengesteckten Komponenten mit eingeträufelter Businesslogik. Hinterfragt wird da nix. Der nächste Sprint lässt das zeitlich nicht zu. Der Code-Sklave bekommt seinen Klassenrumpf mit Unittests und hämmert auf dem Code herum, bis Alles grün ist. Wenn die nicht-funktionale Eigenschaft "Ablaufgeschwindigkeit" missfällt, wird eben schnellere Hardware gekauft. Ist im Zweifel billiger.

    Und dann noch die Phrase "Wir müssen Digitalisieren". Was da gerade an Glücksrittern am Markt unterwegs ist. Katastrophe! Kann die vorherige Aussage nur bestätigen: Fast nirgens werden die Prozesse hinterfragt. So wird aus dem Sch**ss-Prozess, ein digitaler Sch**ss-Prozess. Die Firma versenkt 6-7 stellige Summen, Die Mitarbeiter sind gefrustet, weil die Abläufe jetzt performanter in den fehlerhaften Zustand gehen, aber dafür nicht mehr erkennbar ist, wo es konkret klemmt. Aber der Berater, der sich längst vom Acker gemacht hat, kann locker die letzte Rate vom Eigenheim bezahlen und das neue SUV ist schon geordert. Man muss dem verhassten Nachbarn ja schließlich was bieten. Mission accomplished.

  24. Michael Uray sagt:

    "Aber es gab – bis auf wenige Ausnahmen – keinen Plan, wie die Welt da draußen, die durch Software abgebildet werden sollte, so tickt." – Ich denke, dass ist heute auch immer noch so.
    Man müsste die Entwickler alle einmal selbst mit ihrer Software produktiv arbeiten lassen. Das würde wohl viele Bugs beheben und Verbesserungen einfließen lassen.

    Viele Programmierer interessieren sich glaube ich gar nicht dafür an welchem Produkt sie eigentlich arbeiten "Ich programmiere nur das hinein was man mir sagt".

  25. A. B . sagt:

    Das Grundproblem fehlender Softwarequalität ist meines Erachtens das Internet, das seit 1991 exponentiell vermehrt zur schnellen "Auslieferung" oder zum selbständigen oder automatischen Download von Updates genutzt wurde… Auf die Spitze getrieben von Smartphones mit ihren App-Stores und täglichen Updates…

    Hat die Software einen Fehler? Egal, in 1-2 Wochen (nach Ende des nächsten agilen Sprints) schieben wir schnell ein Update übers Web hinterher. Wird schon kein Anwender sofort merken, wenn mangels vollständiger Qualitätstests noch weitere Fehler enthalten sind. Und wenn doch: Dann schieben wir eben mit dem nächsten Sprint schnell ein weiteres Update raus.

    Die meisten ungeduldigen User wollen lieber die neuste Nightly vom Firefox nutzen als die bewährte ESR-Version…

    Bloß nicht mehr wie früher monate- oder jahrelang im Entwickler-Elfenbeinturm verschanzen, bis am Ende relativ fertig ausgetestete Software herauskommt.
    Der Kunde will heutzutage den Fortschritt agil/live miterleben, auch wenn er alle 2 Wochen nur einen weiteren unwesentlichen Eintrag in einem Auswahlmenü zu sehen bekommt.

    Lange Zeit verschwenden, um alle Requirements zusammenzusammeln – die man dann auch gezielt testen/validieren könnte ? Och nöö, wer noch was dazu haben möchte, kann das als Stakeholder ins Backlog für den nächsten Sprint spontan einbringen. Und viel wichtiger ist es, die Entwickler nicht durch Tests zu nerven, die nur ihre Fehler aufdecken…

    Genügend Zeit in jeden Sprint für Test und Qualitätssicherung der neuen Funktion einplanen ? Ach nee, Testplanen ist ja so unagil ! Und Fehler nach einem Sprint kann man ja immer noch in den nächsten Sprints korrigieren…
    Gesamte Softwareentwicklung terminlich bis zum Ende vorausplanen, auch wenn der ursprüngliche Plan zwischendurch mal angepasst werden muss ? Nääää, wir sind doch nicht im Kommunismus, so ein 5-Jahres-Plan würde eh schief laufen. Lieber das Backlog Sprint für Sprint abarbeiten, und den Stakeholder durch ständiges Vorzeigen von Tippelfortschritten bei Laune halten…auch wenn am Ende noch etliche Sprints ergänzt werden müssen, um wirklich ALLE Requirements und Qualitätsanforderungen zu erfüllen (bzw. bei zugesichertem Liefertermin etliche Sprints/Funktionen wegfallen lassen…Es gibt da ja noch die schöne Update-Funktion per Internet. Und damit hält man sich auch den Kunden bei der Stange.)

    Was interne Tools angeht, hab ich die gleiche Erfahrung auch gemacht:

    Es werden tolle "state-of-the-art" Tools über den grünen Klee gelobt und vorschnell angeschafft, aber gar nicht mehr geschaut, ob es überhaupt einen guten tool-unabhängigen Prozess gibt UND ob diese Tools alle diese gut durchdachten Prozessschritte ausreichend und vor allem durchgängig abbilden, ohne dass man erst noch aufwendig die Schnittstellen zwischen den ach so tollen Tools selbst entwickeln und ständig pflegen muss.

    Hauptsache ein tolles Dashboard für die Projektleiter zur Anzeige des agilen Gesamt-Entwicklungsfortschrittes !

    Wenn eine Firma also noch nicht mal ihre Entwicklungstoollandschaft perfekt geplant und alle beteiligten Tools optimal aufeinander abgestimmt eingerichtet hat, wie soll dann bei der entwickelten Software selber eine gute Qualität herauskommen ?
    Ich sag dazu nur: Software-Konfigurationsmanagement nach EN/ISO10007. Sagt das jemandem etwas ? Den heutigen "Toolies" vermutlich kaum noch…obwohl es eine aktuell gültige Grundsatznorm für jeden SW-Entwicklungsprozess ist, die in manchen "state-of-the-art"-tools aber leider nicht mehr volle Anwendung findet…

  26. Robert sagt:

    Der Unterschied zu anderen Ingenieursdisziplinen ist, dass das Kopieren gratis ist.

    Jede Brücke muss immer wieder von Grund auf neu gebaut werden. Jede Brücke ist auch individuell, denn der Stahl ist aus einer anderen Charge und ein anderer Schweisser hat die Nähte gemacht.

    Wenn es wie Software wäre, könnte gratis und auf Knopfdruck eine Kopie der Brücke erstellt werden und nur die Anpassungen für andere Fundamente müssten teuer angepasst werden.

    Da könnte jeder gratis ein Einfamilienhaus kopieren und müsste nur die Anpassung im Fundament für Strom und Wasser bezahlen. Und eventuell Lizenzgebühren an MicroHome ;-) Und nur Änderungen wie eine andere Farbe oder ein neuer Raum für Fittness oder Weinkeller kostet wirklich Geld. Und etwas entfernen oder aufzuräumen auch, deshalb lässt man das.

    Und nach paar Jahrzehnten hat jedes neue Einfamilienhaus tausend Räume und keiner weiss mehr genau welche. Deshalb fühlt sich Softwareentwicklung auch heute noch immer so wie nach Wildem Westen an.

  27. Ingo E. sagt:

    Hat irgendjemand hier schon mal in der kommerziellen SW Entwicklung gearbeitet?
    Lauter Leute, die von nichts eine Ahnung haben.

    Das Grundproblem ist die Komplexität und die Anzahl der Anforderungen, nichts anderes (vermischt mit schlechten Rahmenbedingungen). Die Kompetenz der Entwickler berührt das alles nur am Rande.
    Ich empfehle die Auseinandersetzung mit dem Thema „Softwarequalität". U.a. dazu das Stichwort „induzierte Fehler" – die meisten Fehler entstehen tatsächlich in der Programmierung, aber sie sind zumeist verhältnismäßig leicht zu finden und zu beheben. Bei Fehlern in den Anforderungen und im Grunddesign sieht es anders aus: Es sind nur wenige Fehler, aber die Auswirkungen können katastrophal und nur sehr schwer zu beheben sein.
    Viele hier denken scheinbar an einzelne Programmierer, die etwas vor sich hin entwickeln und nicht an z.B mehr als 100 Entwickler, die mit Anpassungen an mehr als 100 Altprogrammen 2006 die SEPA Stufe 1 in einer Bank umsetzen mussten. Wenn wie dort, die Programmierung beginnen muss, bevor alle Anforderungen klar definiert sind. Und die Testfenster mit der EZB und der Bundesbank als Erstes feststehen.
    Die meisten hier denken auch nicht an gesetzliche Änderungen, wie z.B. die zur Abgeltungssteuer, als die Umsetzungsverordnungen immer wieder verändert wurden.
    Das sind 2 Beispiele von eher kleinen Projekten, die unter unter enormen Zeitdruck umzusetzen waren.
    Komplexität und Zeitdruck wirken sich viel schwerer aus, als die individuelle Kompetenz eines einzelnen Entwicklers. Natürlich gibt es immer Programmierer, die frisch von der Uni kommen und von nichts eine Ahnung haben, aber daran scheitern Grossprojekte nicht.
    Wenn ich etwas von „ingenieursmässiger" SW Entwicklung an einer Uni lese, lache ich mich tot. Das ist in der echten Welt nicht zu machen.
    Die Komplexität von Grossprojekten wird immer unterschätzt, zumindest zu dem Zeitpunkt, an dem Budget und Termin bestimmt werden.
    Leider reicht meine Zeit und Lust nicht aus, dies alles hier etwas ausführlicher und weniger angreifbar darzulegen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.