Ist Software üblicherweise am Stand der Technik?

Als Gerichtssachverständiger muss ich oft bewerten, ob eine Software dem Stand der Technik entspricht - ob aus technischen Gründen beispielsweise die Abnahme der Software verweigert, Nachbesserungen verlangt oder Schadenersatz gefordert werden kann. Meine Erkenntnis daraus ist:

Software, auch die von den besten Mitarbeitern der renommiertesten Unternehmen, entspricht meiner Erfahrung nach in vielen Fällen nicht dem Stand der Technik.

Das ist meine persönliche Einschätzung, die - da ich zumeist bei Individualsoftware und oft erst bei für den Auftraggeber offensichtlichen Problemen beigezogen werden - vielleicht nicht dem Durchschnitt von Software entspricht. Es ist also notwendig genauer darzulegen, welche Beobachtungen ich immer wieder mache, dass ich zu dieser Einschätzung komme:

• Einsatz ohne Einsatzfähigkeit: Beinahe jede von mir untersuchte Software wurde ohne Wissen zu ihrer Einsatzfähigkeit in Betrieb genommen. "Die Release war für heute angekündigt", "Alle Stories wurden vom Product-Owner abgenommen", "Wir sind agil und haben ohnedies Definitions-of-Done" oder "Unsere Tests sind alle durchgelaufen" sind keine ausreichenden Kriterien für die Einsatzfähigkeit einer Software. Kaum ein Projekt hat vereinbarte und gemessene Testqualitäts- und Testendekriterien, kaum ein Projekt weiß zum Releasetermin Bescheid über die erwartete Fehlerdichte, kaum ein Projekt hat bzw. erfüllt sinnvolle Quality-Gates für die Produktivsetzung.
• Unpassende und falsch umgesetzte Architektur: Viele Projekte verwenden für den jeweiligen Einsatzzweck unpassende und/oder falsch verstandene Architekturen. Falsch eingesetzt werden heutzutage oft Microservices (keine wirklichen Microservices, nicht an Kontextgrenzen geschnitten, viele oder synchrone Abhängigkeiten, fehlende oder versteckte Orchestrierung/Choreographie und Versionsmanagement), Event-Driven Architecture und Eventual Consistency (bei typischen State-fokussierten CRUD Anwendungen ohne Domain-Events), Angular/React Frontends (für langlebige Software trotz fehlendem LTS und Vendor Lock-In) und AI (wo mehr oder weniger komplexe Algorithmen auch ausreichten). 
• Offene technische Schulden: Technische Schulden, egal ob bewusst oder versehentlich, rücksichtslos oder umsichtig aufgenommen, sind oft schon lange bekannt aber bis zum Produktivsetzungszeitpunkt nicht behoben und werden auch im Rahmen der Softwarewartung nicht ausgebaut. Oft ist sogar erkennbar, dass laufend mehr technische Schulden hinzukommen bzw. entdeckt werden, als abgebaut werden. In vielen Projekten sind technischen Schulden derart angehäuft worden, dass deren Behebung extrem aufwändig ist und in vielen Fällen zu Verschlimmbesserungen führt.
• Veraltete Frameworks und Libraries: Software wird mit veralteten Frameworks und Libraries (bzw. veralteten Versionen von Frameworks und Libraries) in Betrieb genommen, und auch während der Softwarewartung werden diese nicht aktualisiert. Oft sind die Versionen bereits so veraltet, dass ein Umstieg auf die neuesten Versionen nur mit mehrmonatigem Aufwand vollzogen werden kann.

Alles Punkte, die für den Stand der Technik von Software entscheidend sind. Jeder Projektmitarbeiter oder Manager kann (ausgenommen beim zweiten Punkt) leicht bewerten ob diese Punkte bei seiner Software auch zutreffen. Jeder Auftraggeber kann sich vom Auftragnehmer diesbezüglich Gewissheit schaffen lassen. Es würde mich freuen, Rückmeldungen à la "bei uns passen diese Punkte" zu bekommen.

Fazit: Meiner Erfahrung nach entsprechen bereits die vier genannten Teilaspekte meist nicht dem Stand der Technik. Da viele andere Aspekte oft auch den Stand der Technik verfehlen, ist meine Einschätzung: Software entspricht oft nicht dem Stand der Technik.