Gute Programmierer – schlechte Software
Warum Software selten dem Stand der Technik entspricht
"Je besser die Programmierer, Architekten und Tester, desto besser die Qualität der Software." Stimmt nicht! Der Alltag eines Gerichtssachverständigen für Softwarequalität zeigt, dass Software – auch die von den besten Mitarbeitern der renommiertesten Unternehmen – nur selten dem Stand der Technik entspricht.
Warum "Stand der Technik"?
Entwickelt man kommerzielle Software, so muss diese wie jedes Produkt bzw. jede Dienstleistung dem Stand der Technik entsprechen. Ansonsten drohen Gewährleistungs- und Schadenersatzforderungen, die auch weit über dem erhofften Umsatz oder Gewinn der Software liegen können. Der Stand der Technik ist dabei nicht einmal eine Eigenschaft, die vertraglich festgesetzt werden muss, da er zu den "Beschaffenheiten, die … üblich und vom Käufer erwartbar sind" (§434 BGB) bzw. "gewöhnlich vorausgesetzten Eigenschaften" (§ 922 ABGB) gehört.
Die einzige juristische Möglichkeit um Gewährleistungs- und Schadenersatzforderungen bei Nicht-Einhaltung des Standes der Technik zu vermeiden, ist, ihn explizit vertraglich auszuschließen. Dazu reicht aber keinesfalls eine allgemeine Klausel z. B. in den allgemeinen Geschäftsbedingungen (vgl. BGH Urteil Az. VII ZR 26/14). Das gilt auch für nicht kommerzielle Software wie Open-Source-Software, deren vertragliche Haftungs- und Gewährleistungsausschlüsse ebenso wirkungslos sind. Aber auf Grund der Tatsache, dass diese Software unentgeltlich ist, haftet man eingeschränkt: In Deutschland nur bei Vorsatz bzw. grober Fahrlässigkeit (§521-524 BGB), in Österreich nur bei voraussehbaren Schäden bzw. Rechtsmängeln (§945 ABGB, OGH 4Ob140/77).
TIPP: Wer Software nicht am Stand der Technik entwickeln kann oder möchte, tut gut daran, dies als Eigenschaft der Software vertraglich festzulegen.
Was ist der "Stand der Technik"
Oft wird fälschlicherweise unter dem Stand der Technik all jenes verstanden, was aktuell, neu und zeitgemäß wäre. Für Software würde demnach gelten, dass Kotlin eher Stand der Technik wäre als Java, Kanban eher als Scrum, Microservices eher als Webservices, Edge Computing eher als Cloud Computing usw. Oft wird unter "Stand der Technik" auch das verstanden, was aktuell gerade prominent auf Fachkonferenzen oder in Fachmagazinen vertreten ist. Demnach wären derzeit beispielsweise Artificial Intelligence, Internet of Things, Blockchain oder Quantencomputing am Stand der Technik. Andere wiederum meinen, der Stand der Technik wäre das, was in entsprechenden Normen beschrieben ist. Demnach würden in der Softwaretechnik die (hunderten) aktuellsten IEEE, ISO, DIN, ÖNORMen den Stand der Technik beschreiben. Das alles ist zwar interessantes und meistens auch sinnvolles Wissen, beschreibt aber nicht den Stand der Technik.
Der Stand der Technik ist kein technischer Begriff, sondern ein juristischer.
Der Stand der Technik ist kein technischer Begriff, sondern ein juristischer. Er ist eine sogenannte Technikklausel – ein in vielen Gesetzestexten verwendeter, aber nicht im Detail im Gesetz definierter Begriff. Das was in den Gesetzen (z. B. Abschnitt 4.5.1/256 Handbuch der Rechtsförmlichkeit oder §71a der Gewerbeordnung) hinsichtlich des Standes der Technik definiert ist, lässt sich folgendermaßen zusammenfassen:
- "Entwicklungsstand" – er entspricht dem auf einschlägigen wissenschaftlichen Erkenntnissen beruhenden Stand der Entwicklung.
- "fortschrittlich" – er ist laufenden Änderungen unterworfen. Fortschritte in der Technologie und in den wissenschaftlichen Erkenntnissen ersetzen den vormaligen Stand der Technik.
- "bewährt" – er beruht nicht nur auf wissenschaftlichen Erkenntnissen, sondern muss sich in der Praxis bewährt haben. Seine Funktionstüchtigkeit muss erprobt und erwiesen sein.
- "zielgerichtet" – er muss die in ihn gesetzten Ziele erfüllen. Dazu gehört nicht nur die Wirksamkeit, sondern auch die Wirtschaftlichkeit.
Entwickelt man kommerzielle Software, so muss diese also auf bewährten, zielgerichteten, fortschrittlichen Techniken und Technologien beruhen, die dem Entwicklungsstand entsprechen. Man tut also gut daran, jede einzelne verwendete Technik und Technologie zu prüfen, ob diese …
- …dem Entwicklungsstand entspricht – dazu beispielsweise aktuelle Bücher, Veröffentlichungen, Fachvorträge existieren.
- …fortschrittlich ist – also nicht beispielsweise durch eine neuere Version oder gar andere Technik oder Technologie abzulösen ist.
- …bewährt ist – dazu beispielsweise Praxisberichte veröffentlicht wurden, die die Einsatztauglichkeit belegen.
- …zielgerichtet ist – es also klar ist, dass damit das zu lösende Problem effizient (wirtschaftlich) und effektiv (wirksam) gelöst werden kann.
TIPP: Wer Software am Stand der Technik entwickelt, tut gut daran, eine Liste aller verwendeter Techniken und Technologien bereitzuhalten, um jederzeit überprüfen und nachweisen zu können, dass diese dem Entwicklungsstand entsprechen, fortschrittlich, bewährt und zielgerichtet sind (So eine Software Bill of Materials (SBOM) wird von Organisationen wie der NSA oder CISA seit langem gefordert).
Entspricht jetzt aber Software üblicherweise dem Stand der Technik?
Betrachten wir die Frage anhand des Einsatzes der prominenten Web-Frameworks Angular und React in aktuell entwickelter Software:
- Entwicklungsstand: Gute Programmierer, Architekten und Tester kennen meist den Entwicklungsstand. Sie bilden sich laufend fort, besuchen einschlägige Konferenzen und tauschen sich auch laufend mit anderen Wissenden aus anderen Unternehmen aus. Sie wissen beispielsweise, dass Angular und React Web-Frameworks am Entwicklungsstand sind. Sie wissen auch, dass die Entwicklung ohne den Einsatz von passenden Frameworks nicht dem Entwicklungsstand entspricht. Was sie aber oft nicht wissen ist, dass aktuell weniger gehypte Web-Frameworks ebenfalls am Entwicklungsstand sind. Der Entwicklungsstand ist eben nicht zwangsläufig in aller Munde.
–> Die meisten Softwareentwicklungsprojekte sind hinsichtlich des Entwicklungsstandes am Stand der Technik.
Software mit veralteten Frameworkversionen ist nicht am Stand der Technik.
- Fortschrittlich: Gute Mitarbeiter wissen meist, ob eine eingesetzte Technologie auch fortschrittlich ist. Sie wissen, dass z. B. Angular-JS noch bis Ende 2021 gewartet wurde, aber seit mindestens 2018 klar war, dass Angular-JS zu Gunsten von Angular aufgegeben wird. Sie wissen auch, dass der Einsatz einer veralteten Version eines Web-Frameworks (also beispielsweise zum Zeitpunkt des Schreibens dieses Artikels alle Versionen vor Angular 13.1.X oder React 17.0.X) nicht "fortschrittlich" und darüber hinaus auch sicherheitskritisch, fehleranfällig und die Wartbarkeit reduzierend sind (Hotfix-Versionen sind diesbezüglich eine Ausnahme. Sie erhöhen nicht die Wartbarkeit und sind auch nicht weniger fehleranfällig. Wenn die Fixes für das gegenständliche Projekt nachweisbar irrelevant sind, ist auch die letzte Minor-Version hinsichtlich des Standes der Technik als fortschrittlich zu bewerten). Dennoch kann man beobachten, dass eine Vielzahl an Softwareentwicklungsprojekten mit veralteten Library- und Frameworkversionen in Einsatz geht und auch während der Wartung bei neuen Releases der Software die Versionen nicht aktuell gehalten werden. Derartige Software ist hinsichtlich der Fortschrittlichkeit somit definitiv nicht am Stand der Technik. Das betraf beinahe 100 Prozent aller vom Autor bisher begutachteter Software.
–> Viele Softwareentwicklungsprojekte und die meisten Wartungsprojekte sind hinsichtlich der Fortschrittlichkeit nicht am Stand der Technik. - Bewährt: Gute Mitarbeiter werden stets danach trachten, bewährte Technologien statt im Vergleich dazu kaum bewährte und vergleichsweise auch kaum getestete und enorm wartungsintensive Eigenentwicklungen einzusetzen. Ob eine Technologie sich in der Praxis auch bewährt hat, wissen die meisten hauptsächlich auf Grund eigener Erfahrungen oder Erfahrungen von Kollegen. Auf Konferenzen, Meet-ups und dergleichen kann man auch diesbezüglich einiges in Erfahrung bringen. Angular und React sind weltweit derart oft eingesetzte Frameworks, dass man davon ausgehen kann, dass sie sich in vielen verschiedenen Situationen auch bewährt haben. Bei weniger weit verbreiteten Techniken und Technologien tut man aber gut daran, diese zuerst einer Bewährungsprobe zu unterziehen – z. B. im Rahmen eines Spikes oder Walking-Skeletons und immer mit einem möglichen Ausstiegs- oder Alternativszenario.
–> Hinsichtlich des Einsatzes von bewährten Technologien sind die meisten Projekte am Stand der Technik. - Zielgerichtet: Gute Mitarbeiter wissen, welche Technologien und Techniken in der Lage sind, die Aufgaben der umzusetzenden Lösung zu erfüllen. Dennoch findet man in der Praxis in abnahmebereiter oder in Wartung befindlicher Software immer wieder Bestandteile, die "aus historischen Gründen" so sind. Den Mitarbeitern ist also (inzwischen oder immer schon) klar, dass diese Teile zwar die Aufgabenstellung lösen, aber eben nicht zielgerichtet. Darüber hinaus kann beobachtet werden, dass auch gute Mitarbeiter dazu neigen, neuen bzw. gehypten Technologien eine Effizienz zuzusprechen, die durch nichts belegt werden kann. Oft wird auch vergessen, dass nur ein kleiner Teil der Aufwände in der Programmierung steckt – erhöhte Produktivität in der Entwicklung ist jedoch nur dann sinnvoll, wenn andere Bereiche des Software Lifecycles (wie z. B. Recruiting, Lernkurve, Build, Test, Wartung) nicht darunter leiden. Der Einsatz von Angular und React verlangt beispielsweise üblicherweise, dass man parallel zum Backend einen gänzlich anderen Entwicklungs- und Frameworkstack unterhält und unterschiedliche Konzepte und Paradigmen einsetzt. Diese oft vernachlässigten aber enormen zusätzlichen Kosten gepaart mit dem im Vergleich zu Backend-Technologien extrem kurzen "Long-Term"-Support (z. B. bei Angular 12 Monate, bei React gar kein LTS) und fehlenden Abwärtskompatibilitäten (z. B. nicht abwärtskompatible Releases bei Angular alle 6 Monate, bei React alle 1-3 Jahre) sind in vielen Projekten nicht als zielgerichtet zu bewerten.
–> Software basiert in vielen Fällen auf nicht zielgerichteten Technologien und ist daher oftmals nicht am Stand der Technik.
Betrachtet man andere Bereiche der Softwareentwicklung als den Einsatz von Web-Frameworks, so kann man ähnliche Probleme hinsichtlich des Standes der Technik beobachten:
- Jedermann weiß, dass die parallele Verwendung mehrerer Sprachen in einem einzigen Projekt zu Verwirrung und Missverständnissen führen. Dennoch wird die Möglichkeit, mehrere Programmiersprachen bei der Umsetzung von z. B. Web/Microservices zu verwenden (Stichwort "Polyglot Programming") oft als Vorteil angeführt. Dass man aber die Businesslogik nicht teilweise in z. B. C# und PL/SQL schreibt, wird heutzutage meist als gut und richtig empfunden.
- Der Einsatz von Test-driven Development (TDD) gilt bereits seit vielen Jahren als fortschrittlicher als das Schreiben von Unit-Tests nach der jeweiligen Programmierung. TDD führt bei gleichem Aufwand nicht nur zu besser testbarer und besser getesteter Software, sondern führt auch zu besserem technischen Design. Dennoch wird TDD nicht in jeder aktuellen Softwareentwicklung verwendet.
- Der Einsatz von Werkzeugen zur Messung der Code-Qualität und Sicherstellung von Quality-Gates ist ebenfalls seit vielen Jahren Stand der Technik. Dennoch findet man immer wieder Projekte, bei denen derartige Werkzeuge nicht – oder unbegründeterweise nur auf wenige Metriken reduziert – eingesetzt und Quality-Gates regelmäßig missachtet werden.
- Die Definition und Prüfung von Testende-Kriterien ist beim Testen von Software bekanntermaßen notwendig, um zu verhindern, dass das Testen fälschlicherweise als abgeschlossen betrachtet wird. In vielen Projekten gibt es aber keine Testende-Kriterien – der Test gilt als abgeschlossen, wenn alle oder bestimmte vorhandene Testfälle erfolgreich getestet wurden. Man hat üblicherweise keine Ahnung, wie viele Fehler nach dem Test noch in der Software vorhanden sind und ob die Software überhaupt hinsichtlich ihrer Fehlerrate als produktionsreif einzustufen ist.
- Große Firmen setzen oft auf den Einsatz mächtiger kommerzieller Applikations- und Datenbankserver – auch dann, wenn ihre Software zielgerichteter (da wirtschaftlicher) mit Open-Source-Servern oder in gar in der Cloud (Platform as a Service) betrieben werden könnte.
- Artificial Intelligence und Blockchain, aber auch Event-driven Architecture (und Event Streaming, Event Sourcing), Microservices, Funktionale Programmierung oder (Industrial) Internet of Things sind aktuell derart gehypte Technologien, dass sich viele Firmen und Softwareentwickler überlegen, was sie nur mit diesen Technologien umsetzen könnten. Das führt einerseits dazu, dass diese Technologien oft dann eingesetzt werden, wenn alternative Technologien zielführender wären, andererseits, dass technologisch interessante, statt für die Anwender zielführende Dinge umgesetzt werden.
- Die laufende Aktualisierung der verwendeten Frameworks wird oft – insbesondere in der Wartungsphase – auf die lange Bank geschoben. Ereignisse wie der 0-day log4j Exploit vom 09.12.2021 oder die Abschaltung von reCAPTURE v1 am 31.3.2018 führen dann zu unerwartet hohen Aufwänden (da bei mehreren Frameworks mehrere nicht abwärtskompatible Major-Versionen übersprungen werden müssen). Da diese Aufwände nicht in kürzester Zeit erbracht werden können, führt das unweigerlich zu Schäden oder zur Abschaltung von Software(teilen).
Zusammengefasst kann also folgendes festgestellt werden:
- Software ist hinsichtlich der Versionen der verwendeten Libraries und Frameworks oft nicht am Stand der Technik.
- Es werden oft Technologien und Techniken eingesetzt, die für das konkrete Projekt nicht zielgerichtet und somit nicht Stand der Technik sind.
- Es werden oft Technologien und Techniken nicht oder nur ungenügend eingesetzt, obwohl bekannt ist, dass ihr Einsatz im konkreten Projekt Stand der Technik wäre.
Der Schluss ist also zulässig, dass Software nur selten dem Stand der Technik entspricht.
TIPP: Bei der Aufnahme eines weiteren Elementes in die Liste aller verwendeter Techniken und Technologien sollte geprüft werden, ob es auch für das konkrete Projekt belegbar (und nicht nur vermuteterweise) zielgerichtet ist (und nicht nur gehypt, neu oder interessant ist). Des Weiteren sollte geprüft werden, ob nicht Techniken und Technologien fehlen, deren Einsatz für das Projekt Stand der Technik wäre. Und schlussendlich sollten die Einträge in der Liste regelmäßig überprüft werden, ob sie noch dem Entwicklungsstand entsprechen und wenn das aus technischen Gründen nicht möglich ist, dies auch entsprechend dokumentiert werden.
TIPP: Die Roadmaps aller verwendeter Libraries und Frameworks sollten im Auge behalten werden und gegebenenfalls der Zeitpunkt der eigenen Releases darauf abgestimmt werden: Alle verwendeten Libraries und Frameworks sollten bei Beginn der Releases auf den aktuellen Stand gebracht werden. So hat man einen ganzen Release Zeit, um am Ende des Releases auch getesteterweise auf dem Letztstand der Libraries und Frameworks zu sein. Ein vom Stand der Technik her ohnedies geforderter hoher Abdeckungsgrad durch automatisierte Tests hilft dabei ungemein.
Warum aber entspricht Software – auch die von den besten Mitarbeitern der renommiertesten Unternehmen – selten dem Stand der Technik? Fragt man die handelnden Personen, so bekommt man meist Antworten wie: Features würden gegenüber der Technik priorisiert. Das Management gäbe dafür keine Zeit/ kein Budget oder die Software sei ohnedies am Stand der Technik.
Die letzte Antwort wurde bereits für das Gros der Software falsifiziert. Die anderen Antworten sind vermutlich oft korrekt, schieben aber nur die Verantwortung von der Projektorganisation weg. Softwareentwicklungs- und Wartungsprozesse, die dem Stand der Technik entsprechen, sind aber von externen Einflüssen unabhängig. Sie sollten – unabhängig von der Qualität der Projektumgebung – immer Software am Stand der Technik liefern. Unabhängig davon, wie sehr die Auftraggeber eine Priorisierung der Features fordern oder wie niedrig das finanzielle oder zeitliche Budget für die Umsetzung einer Software angesetzt ist, professionelle Teams liefern Software immer am Stand der Technik und entfernen auch laufend neu erkannte technische Schulden.
Die üblichen Antworten lassen also darauf schließen, dass die Softwareentwicklungs- bzw. Wartungsteams selbst nicht in der Lage sind, Software am Stand der Technik zu liefern. Dabei mangelt es meist weniger am Know-how, sondern eher am Durchsetzungswillen und -vermögen der Teams selbst. Zähneknirschend wird gehorsam schlechte Software abgeliefert. In anderen Branchen oder auch in anderen Bereichen desselben Unternehmens wäre so ein Vorgehen undenkbar.
TIPP: Ist ein Softwareentwicklungs- oder -wartungsteam nicht in der Lage, Software am Stand der Technik zu liefern, so sollte das Team dahingehend (technisch und organisatorisch) gestärkt werden, selbst zu entscheiden, wie – nämlich am Stand der Technik – und daraus resultierend auch in welchem Zeitrahmen die von außen kommenden Anforderungen umgesetzt werden.
3 Thesen, warum Software selten dem Stand der Technik entspricht:
|
Moderne Architekturen, Programmiersprachen, Technologien und Werkzeuge sind, wie schon oben besprochen wurde, nicht unbedingt Stand der Technik. Auch wenn sie vielleicht dem Entwicklungsstand entsprechen, fortschrittlich und bewährt sind, so sind sie per se nicht zielgerichtet. Das gilt nicht nur für die aktuell gehypten Technologien, sondern auch für früher gehypte und inzwischen bereits im Mainstream angekommene Technologien wie beispielsweise Microservices und Event-driven Architekturen.
Wie schon oben ausgeführt sind insbesondere die meisten JavaScript-Frameworks wegen der Notwendigkeit, einen zweiten Entwicklungs- und Frameworkstack zu unterhalten, am Frontend unterschiedliche Konzepte und Paradigmen als am Backend einzusetzen und ihres – im Vergleich zu den Projekten – oft viel zu kurzen Lebenszyklus' für viele kommerzielle Softwareprojekte als nicht zielgerichtet und somit nicht Stand der Technik einzustufen.
Als Stand der Technik wäre für derartige Projekte beispielsweise Vaadin-Flow zu erwähnen. Es bietet Long-term Support von 5 Jahren (plus 10 Jahre kommerziell), ermöglicht Web-Applikationen rein in Java (d. h. auf einem einzigen Stack mit überall gleichartigen Konzepten und Paradigmen und somit produktiver) zu schreiben und übernimmt als Full-Stack Framework im Vergleich zu JavaScript-Frameworks wesentlich mehr Funktionalität, was viel Code und somit Aufwand und Bugs erspart. Aber auch Vaadin ist nicht für alle typischen kommerziellen Projekte geeignet: Vaadin kann zwar mehrere tausend concurrent User pro Server bedienen, aber auf Grund des Server-States kommt es ohne komplizierte Session-state Replikation bei Serverausfällen zu Verlusten der aktuellen Sessions, was nicht in jeder Software vertretbar ist. In diesem Fall ist – wenn fachlich möglich – eine Architektur gänzlich ohne Server-state (auch in z. B. Datenbanken oder Filestores) wiederum zu bevorzugen.
Auch andere moderne Technologien entsprechen in vielen Projekten nicht dem Stand der Technik, da sie für das jeweilige Projekt nicht zielgerichtet sind. Hier ein paar Beispiele aus der Praxis:
- Verwendung von Hazelcast zur Spiegelung von Caches damit eine Anwendung Hot-failover- bzw. clusterfähig wird. Statt Überprüfung der Caches, ob diese überhaupt sinnvoll und im laufenden Betrieb von unterschiedlichen Nodes veränderbar sind.
- Verwendung von Artificial Intelligence zur Bewertung von Vibrationen von Windrädern hinsichtlich Reparaturnotwendigkeit. Wurde früher durch Umwandlung der Vibrationen in hörbare Frequenzen und von entsprechend geschultem Personal entschieden. Statt der AI hätte man auch eine simple Fouriertransformation und Frequenzanalyse implementieren können.
- Verwendung von Event-Streaming mit Apache Kafka für eine Anwendung, die den (langlebigen) Status von Bauvorhaben abbildet.
- Verwendung eines Instant-Messaging Jabber Frameworks (geeignet für Chats mit Freunden) zur 1:1-Kommunikation zwischen Servern.
- Verwendung eines ELK-Stacks (Elasticsearch, Logstash, Kibana) für simples Error-Logging.
In vielen Fällen entscheidet man sich für den Einsatz dieser Technologien, weil Entwickler oder andere davon überzeugt sind, mit diesen Technologien die Aufgabenstellungen zielgerichtet lösen zu können. Oftmals eine auf keinerlei quantifizierbaren Erfahrungswerten beruhende Überzeugung, die die Firmen Unsummen kostet, nur um den handelnden Personen die Arbeit mit einer neuen, interessanten, modernen Technologie zu ermöglichen.
Der Einsatz moderne Architekturen, Programmiersprachen, Technologien oder Werkzeuge führt somit oft zu einer nicht dem Stand der Technik entsprechenden Software, weil trotz gegenteiliger Beteuerung die Wirtschaftlichkeit bei der Entscheidung weniger Einfluss hat, als das persönliche Interesse der handelnden Personen.
TIPP: Insbesondere bei der Entscheidung für moderne Architekturen, Programmiersprachen, Technologien oder Werkzeuge ist es sinnvoll, erfahrene, externe, nicht am Projekt beteiligte Berater und Sachverständige hinzuzuziehen, die in der Lage sind, diese Entscheidungen mit quantifizierbaren Erfahrungswerten zu untermauern und auch für ihre Empfehlungen haften.
Warum aber sollten gute Programmierer, Architekten oder Tester zu Software führen, die nicht dem Stand der Technik entspricht? Sollten nicht gerade gute Leute besonders viel Erfahrung mit den gängigen Techniken und Technologien haben und damit produktiv und zielgerichtet Software am Stand der Technik entwickeln?
Die Frage, die sich stellt ist: "Was macht einen guten IT-Mitarbeiter aus? Warum ist er/sie besser als andere?" Ist es die Ausbildung? Oder die Breite und Tiefe des Wissens? Oder die emotionale Intelligenz? Das spielt sicherlich alles eine Rolle. Ich bin aber überzeugt davon, dass die praktische Erfahrung mit all den Technologien und Techniken in der IT eines der wichtigsten Kriterien ist. Was nützt einem die beste Ausbildung, das tiefstmögliche theoretische Wissen zu einer Technologie und der intelligenteste Umgang mit anderen Mitarbeitern, wenn man keine Erfahrung hat, um bewerten zu können, ob die Technologie sich auch in der Praxis bewähren kann.
Erfahrung mit Technologien oder Techniken sammelt man idealerweise im Rahmen von realen Projekten, wo diese auch eingesetzt werden. Gute Programmierer, Architekten oder Tester haben also praktische Projekterfahrung mit all den Technologien und Techniken, die in der jeweiligen Situation Verwendung finden. Für die meisten Projekte kommen sinnvollerweise dutzende Technologien und Techniken zum Einsatz kommen, und der Stand der Technik entwickelt sich in der IT rasant weiter. Gute Programmierer, Architekten oder Tester müssen daher gerne neue Technologien und Techniken lernen und auch Überzeugungsarbeit leisten, damit sie diese Dinge auch tatsächlich im Rahmen von realen Projekten einsetzen dürfen. Da zur Vorhersage der Produktivität im gegenständlichen Umfeld die jeweiligen Rahmenbedingungen (z. B. vorhandenes Know-how, Teamgröße, geplante Wartungsänderungen und Produktlebensdauer) individuell berücksichtigt werden müssen, muss sich hier ein Unternehmen auf die Empfehlungen von Experten verlassen. Da liegt es auf der Hand, dass den Empfehlungen der in den Unternehmen als gut anerkannten Personen auch meistens unwidersprochen gefolgt wird.
Der Bedarf der guten Mitarbeiter, Technologien und Techniken einzusetzen, in denen sie selbst noch wenig praktische Erfahrung haben, verstärkt somit die ohnedies bereits vorhandene Tendenz, die Wirtschaftlichkeit der Entscheidungen nicht zu hinterfragen und somit Software zu entwickeln, die nicht dem Stand der Technik entspricht.
TIPP: Bei der Auswahl von Technologien und Techniken, bei denen im Unternehmen noch nicht nachvollziehbar klar ist, ob diese für das jeweilige Projekt wirtschaftlich sinnvoll sind, sollte den diesbezüglichen Beteuerungen auch der besten Projektmitarbeiter kein Glaube geschenkt werden. Neben der bereits erwähnten Alternative des diesbezüglichen Einsatzes externer Experten, wäre die Verwendung der empfohlenen Technologien und Techniken in internen Projekten, die nicht dem Stand der Technik entsprechen müssen, eine weitere Alternative. Messungen und Reflexion, wie sich die Technologien und Techniken auf die Wirtschaftlichkeit des Projektes auswirken, könnten dann Klarheit schaffen.
Aber wie sollte es möglich sein, dass alle Beteiligten auf ihre Leistung stolz sind, obwohl Software entwickelt wurde, die nicht dem Stand der Technik entspricht? Am Ende eines Projektes sollte ja inzwischen allen Beteiligten klar sein, dass sie veraltete und/oder unwirtschaftliche Technologien und Techniken eingesetzt haben.
Historische Gründe sind keine Entschuldigung für die Gegenwart.
Dass veraltete oder unpassende Technologien und Techniken eingesetzt werden, fällt in den meisten Projekten den Beteiligten auf. Die Erklärung dafür lautet zumeist "historische Gründe" bzw. "zu hohe Kosten, das zu korrigieren". "Historische Gründe" sind zwar eine valide Erklärung der Vergangenheit, aber keine Entschuldigung für die Gegenwart. Wenn dem so wäre, würden wir immer noch in Höhlen leben oder mit Lochkarten arbeiten. Bei der Entscheidung für den Einsatz neuer Technologien und Techniken werden auch keine historischen Gründe geltend gemacht, warum also beim Beharren auf ehemaligen und inzwischen erkannten Fehlentscheidungen?
Dass der Einsatz einer Technologie oder Technik unwirtschaftlich war, fällt hingegen in den meisten Projekten nicht auf. In den meisten Fällen wird ja nicht die Produktivität in den einzelnen Phasen des Produktlebenszyklus gemessen. Ob eine bestimmte Technologie die Produktivität positiv oder negativ beeinflusst hat, lässt sich daher meist nicht objektiv feststellen. Feststellen lässt sich meist folgendes: Wird eine Technologie oder Technik mit Begeisterung eingesetzt, so wird ihr Einsatz auch als produktiv empfunden. Wird man zum Einsatz "gezwungen", sinkt auch die subjektiv empfundene Produktivität. Dieses Empfinden ist aber ein schlechter Indikator für die Produktivität, einerseits da es in vielen Fällen nachweisbar nicht mit der tatsächlichen Produktivität korreliert und andererseits, da es nur auf den jeweils betrachteten Teil des Produktlebenszyklus beschränkt ist. Man ist also üblicherweise auch mit der Wahl unwirtschaftlicher Technologien zufrieden.
Die Kosten, veraltete, unpassende oder unwirtschaftliche Technologien und Techniken durch solche zu ersetzen, die dem Stand der Technik entsprechen, sind aber tatsächlich nicht vernachlässigbar. Wenn man es verabsäumt hat, das Projekt während der gesamten Entwicklungszeit am Stand der Technik zu halten, ist es oft enorm teuer, es für die Produktivsetzung bzw. in der Wartung durch geeignete Maßnahmen auf den Stand der Technik zu bringen. Im Gegensatz zu laufenden Aktualisierungen, die in der IT üblicherweise weniger Kosten verursachen als sie Einsparungen bringen, amortisieren sich die Kosten für derart umfassende Veränderungen erst nach Jahren – oft nicht bis zum Lebensende der Software.
Da die Kosten für diese Maßnahmen so hoch sind, werden sie in den seltensten Fällen umgesetzt. Dem Management ist dabei oft gar nicht bewusst, dass sie durch diese Entscheidung die impliziten vertraglichen Anforderungen an die Software missachten, eine verweigerte Abnahme oder hohe Gewährleistungs- und Schadenersatzforderungen riskieren. Auf jeden Fall ist die Tatsache, dass die Software nicht dem Stand der Technik entspricht, kein großes Managementthema. Die Architekten, Programmierer und Tester maulen vielleicht, da sie spüren, dass die Software veraltet und Fehlerbehebungen bzw. neue Anforderungen immer aufwändiger umzusetzen sind. Aber da sie beim Management diesbezüglich kein Gehör finden bzw. sich selbst für diesen Missstand nicht verantwortlich fühlen, trübt das ihr Bild ihrer eigenen Leistung nur marginal.
Dass Software nicht dem Stand der Technik entspricht, ist vielen der Beteiligten nicht klar, und wenn, dann sehen sie es nicht als Manko ihrer eigenen Leistung. Üblicherweise ist man daher auf Software, die nicht dem Stand der Technik entspricht, genauso stolz, wie auf solche, die entspricht.
TIPP: Wer erkennt, dass die Software nicht dem Stand der Technik entspricht, weil sie z. B. in Teilen veraltete oder unpassende Technologien einsetzt, tut gut daran, das Management nicht auf die technischen Einzelheiten, sondern auf das Verfehlen des Standes der Technik und die daraus resultierenden juristischen Konsequenzen hinzuweisen.
TIPP: Um juristische Folgen zu reduzieren, tut man aber gut daran, das Verfehlen des Standes der Technik mit dem Auftraggeber zu klären. Auch Auftraggeber haben meist kein Interesse, ihre Software auf dem Klagsweg in Richtung Stand der Technik zu bringen oder gar den Auftrag rückabzuwickeln.
TIPP: Software bringt man am günstigsten durch sukzessive aber konsequente Verbesserung an den Stellen, die ohnedies aus anderen Gründen angefasst werden, auf den Stand der Technik. Dies kann auch im Rahmen einer bedingten Abnahme geschehen. Die bewusste Planung und Umsetzung der dafür nötigen Verbesserungen im Rahmen von fachlichen Anforderungen, sowie Quality-Gates, die rein auf geändertem und neuem Code fokussieren, helfen dabei ungemein.
