Category Archives: Software Engineering

Erfolgreiches Software Engineering erfordert mehr als nur mittelmäßig gut ausgebildete Programmierer und Tester


In der Computerwoche vom 30.8.2016 liest man:

Kurz- und mittelfristig erföffnet die Digitalisierung Softwareentwicklern gute Aussichten: Sie werden für die Ablösung der Altsysteme gebraucht. Um sie voranzutreiben, braucht es Softwareentwickler. Besonders im deutschsprachigen Raum ist der Beruf des Programmierers aber nicht so angesagt wie er sein sollte.

Meine Meinung dazu:

  • Nur wenige Programmierer sind das, was ich als kompetente Software-Entwickler bezeichnen würde.
     
  • Ihren Chefs scheint das selten klar zu sein.

    Zudem glaubt man allzu oft, als Software-Entwickler schlecht ausgebildete Programmierer & Tester einsetzen zu können (um so Geld zu sparen).
     
  • Diese Fehleinschätzung wird sich rächen.
     
  • Erste Anzeichen dafür, dass ich recht haben könnte, gibt es schon.

 
Mein Eindruck:

Wenn man heute von Programmierern spricht, sind damit nicht selten nur noch Leute gemeint, die mehr oder weniger kompetent an Code rumfummeln können und SCRUM für ein Synonym modernster Projektabwicklungsmethodik halten.

Für die Beseitigung kleiner Fehler mag das ja gerade noch ausreichen. Komplexe unternehmens­kritische Legacy Software auf neue Technologie zu migrieren reicht es aber keinesfalls. Was dabei herauskommt sind Desaster wie das in Kalifornien: Beim Versuch, das Payroll System des Staates neu zu implementieren hat man gleich zwei Mal Schiffbruch erlitten. Der zweite Auftragnehmer (immerhin SAP) musste sich schließlich bereit erklären, Schadenersatz in Höhe von 59 Millionen Dollar zu zahlen und auf weitere 23 Millionen Dollar eigener Forderungen zu verzichten.

Wie wenig kompetent Software-Entwicklungs-Teams gelegentlich sein können, zeigt auch ein Beispiel aus 2012.

2011 wurden nicht weniger als zehn ähnlich umfangreiche Projektkatastrophen bekannt. Alle hatten ERP Software zum Gegenstand, Software also, welche die Existenz der Unter­nehmen, die sie einsetzen, gefährden kann, wenn sie nicht richtig funktioniert.

Besonders lehrreich ist der Fall in Großbritannien, wo ein Schaden von 11 Mrd. Pfund entstand u.A. deswegen, weil die mit der Implementierung des nationalen Verwaltungssystems für Patientendaten beauftragten Software-Entwickler (in diesem Fall CSC) bis zuletzt nicht erkannten, dass sie mit der Realisierung der Software überfordert waren: [B].

Über falsch verstandene “Agile” Methodik


Wer mich kennt der weiß:

Ich bin ein erklärter Gegner der im Agile Manifesto postulierten Methodik und der daraus entstandenen — völlig ungeeigneten — Software-Entwicklungs-Modelle, für die heute SCRUM schon fast als repräsentativ gilt.

Am deutlichsten habe ich meine Warnung vor solch verwerflichen Formen von Agile wohl zusammengefasst auf den beiden Seiten

Man sollte daraus nun aber nicht schließen, dass ich ein Gegner heute notwendig gewordener Agilität wäre.

Ganz im Gegenteil: Mir ist klar, dass spätestens ab der Jahrtausendwende agiles Vorgehen unverzichtbar geworden ist — die im Manifesto vorgeschlagene Lösung allerdings kann nur ins Verderben führen (denn sie ist undurchdacht und beispiellos naiv).

Meine Ansicht darüber, wie Agilität verstanden und gelebt werden sollte, ist definiert auf den beiden Seiten:

Um zu zeigen, dass ich keineswegs der einzige bin, der “Agile” und SCRUM für absolut ungeeignet — ja sogar gefährlich — hält, seien hier Links hin zu Meinungen Dritter aufgelistet, die ebenso denken wie ich und die aus eigener negativer Erfahrung heraus zu dieser Einstellung kamen:

  • Gartner fand heraus …
     
  • Michael O. Church — heute bei Google — sah durch Umstieg auf SCRUM ein schon börsen-notiertes Startup-Unternehmen zugrunde gehen. Er schreibt wörtlich: “This shit is toxic, it needs to die yesterday.”
     
  • Erik Meijer, ein mehrfach preisgekrönter Fachmann für Software-Entwicklung, nennt SCRUM ein “Krebsgeschwür”.

Weitere Meinungen:

Historisch gesehen, gilt:

Die extrem bürokratisch angelegten Vorgehensmodelle, die

  • zunächst in den USA durchs DoD (Department of Defence) zur Pflicht gemacht wurden,
  • dann aber — in Nachahmung davon — auch in Deutschland als sog. V-Modell (entwickelt von der IABG) sogar Behördenstandard wurden,

mussten irgendwann zu einer Gegenreaktion, zu einem Befreiungsschlag führen. Er kam in Form der Agilen Bewegung, war aber nicht durch entspre­chende Forschung unterstützt, und hat daher zu einem geradezu lächer­lichen Modell geführt, dessen Aushängeschild sich SCRUM nennt und fast schon als verdammenswert einzustufen ist).

Erst nach 2000 wurde einigen wenigen klar, wie ernst man die Gefahren dieser neue Bewegung nehmen muss. Weltweit anerkannte Methodiker des Software-Engineerings, die ihre Stimme hätten erheben können, waren da aber just schon alle aus dem aktiven Berufsleben ausgeschieden.

Nur so ist erklärbar, dass diesem ganzen Unsinn bis heute kein Einhalt geboten wurde …

Erfahrene Software-Entwickler wissen: Um agil zu sein, reicht es völlig

  • das klassische Wasserfallmodell spiralförmig anzuwenden (sprich: zuzu­geben, dass jede seiner Phasen erst zu Projektende abgeschlossen sein kann)
  • und allzu bürokratische Regeln des V-Modells einfach zu ignorieren (es also projektspezifisch zu verschlanken).

Natürlich wird, damit der Auftragnehmer auch im Kontext von Festpreisprojekten nicht ungebührend benachteiligt wird, jede Abänderung einer durch beide Parteien als zunächst fertig akzeptierten Version des Pflichtenheftes einer geeigneten Vertragserweiterung bedürfen (Change Management).
 

Fehlende Software-Qualität kann auch große Unternehmen gefährlich stolpern lassen!


Dass fehlende Qualität von Software ein Unternehmen in Krisen führen kann, bestätigt sich auf jeden Fall dann, wenn anhaltende Probleme mit einen unter­nehmenskritischen neuen System den CFO zu einer Gewinnwarnung zwingen und so auch die Aktionäre beunruhigen.

Sie glauben nicht, dass so was passiert? Nun, hier ist ein Beispiel:

Wie die Computerwoche berichtet, droht das misslungene neue Computersystem “New Forwarding Environment” (NFE) die Deutsche Post im Frachtgeschäft um Jahre zurückzuwerfen.

Deteils finden sich auf FinanzNachrichten.de in einer Meldung vom 29.10.2015:
 

    Larry Rosen, der Finanzchef der deutschen Post, erklärt, NFE sei zu fehleranfällig und müsse wohl ersetzt werden, was Jahre dauern könne, denn eine neue, weniger komplexe Lösung stehe kurzfristig nicht zur Verfügung.

    Man überlege nun, schrittweise neue Komponenten zu integrieren und habe Rückstellungen in Höhe von 37 Millionen Euro gebildet für Ausgaben zur erwarteten Rückabwicklung des Systems in den bereits umgestellten Pilotländern.

    Der Bonner Konzern schätze die Wahrscheinlichkeit, aus dem derzeitigen System positive Effekte erzielen zu können, als sehr gering ein und habe deshalb auch Abschreibungen in Höhe von 309 Mio. Euro vorgenommen.

    Die bereits nach dem zweiten Quartal 2015 schon einmal korrigierte Prognose sei nun nicht mehr zu halten.

 

Nachdenklich macht: NFE basiert auf Software von SAP und wurde mit IBM Global Business Services als Implementierungspartner umgesetzt.

Da sollte man sich schon fragen, wie es zu einem solchem Unglück kommen konnte.

Eines dürfte klar sein:

Obgleich zu akzeptabler Software-Qualität weit mehr gehört als nur die Abwesen­heit von Programmierfehlern, wird sie doch (vom Software-Lieferanten) gerne auf genau solche reduziert gesehen. Dem Auftraggeber fällt das zunächst gar nicht auf.

Doch können denn wirklich nur Programmierfehler so ein Desaster verursachen, wenn das System auf Code beruht, den SAP und IBM entwickelt haben (Firmen also, von denen man erwartet, dass sie kompetentes Personal einsetzen)?

Meine etwa 30-jährige Erfahrung mit Software-Entwicklung sagt mir, dass ein System, dessen Anforderungen vor Beginn der Programmierung genau und vollständig schriftlich spezifiziert und entsprechend gründlich durchdacht worden sind, von erfahrenen Programmierern auf keinen Fall derart verkorkst werden kann, dass es nicht gelingt, alles wesentliche Fehlverhalten innerhalb weniger Monate, wenn nicht Wochen, beseitigen zu können.

An was aber mag es denn dann liegen, dass selbst weltweit bekannte Software-Lieferanten wie IBM — solche, denen man größtmögliche Erfahrung unterstellt — ein System abliefern, welches seine Anwender und Betreiber als kaum nutzbar, auf jeden Fall aber als nicht länger tragbar einstufen?

Mein Verdacht: Man wird wohl versucht haben, nach dem Agilen Manifest zu arbeiten — nach dem Vorgehensmodell also, das seit der Jahrtausendwende unter dem Label “Agile” hochgelobt wird, weil junge Entwickler sich nicht mehr die Mühe machen wollen, die klassischen Verfahren des Software-Engineerings wirklich zu verstehen und der inzwischen neu hinzugekommenen Notwendigkeit, maximal flexibel zu sein, erfolgreich anzupassen — auch und gerade unter der Neben­bedingung, dass heute fast alle Entwicklungsaufträge zum Festpreis vergeben werden.

Wenn die Deutsche Post jetzt plant — und sich sogar gezwungen sieht — “eher evolu­tionär” vorzugehen (wie Rosen sich ausdrückt), klingt mir das schon fast nach einer Wiederholung des von mir vermuteten Fehlers.

Will man wirklich riskieren, dass ich recht habe? Will man nicht zuerst über die Ursachen des Mißerfolgs nachzudenken?

Oder will man einfach nicht einsehen, dass der klassische Weg, Software zu ent­wickeln, eher Erfolg garantiert als SCRUM-artig gestaltete Prozesse in Kombination mit dem blinden Glauben an die Effektivität der allzu naiven Prinzipien des Agilen Manifests?

Ist uns denn nicht bewusst, dass Agile, SCRUM und dieser ganze verhängnisvolle, viel zu wenig durchdachte Trend auf eine kleine Gruppe von Wartungsprogram­mieren zurückgehen, die dachten zu wissen, wie man wirklich große Software-Entwicklungsprojekte so durchführt, dass (fast) nichts mehr schief gehen kann?

Wer glaubt, man könne die Wahl des Prozessmodells zur Entwicklung einer umfangreichen IT-Lösung einfach der Mode oder nur an ihren Code denkenden Programmierern überlassen, der irrt gewaltig.

Dem CIO der Deutschen Post jedenfalls kann man nur raten, die Ursachen seines Desasters genau zu identifizieren.

Versäumt er das, könnte die Deutsche Post in einer eher noch folgenreicheren IT-Sackgasse landen. Ob es dann noch reichen würde, einfach nur eine Gewinn­warnung herauszugeben, kann bezweifelt werden.
 

Zu ungenaue Dokumentation von Software-Anforderungen kann enorme Schäden verursachen


Anforderungen an unternehmenskritische Software müssen schriftlich, genau und vollständig dokumentiert sein.

Welch gewaltiger Schaden entstehen kann, wenn man das nicht beherzigt, zeigen die folgenden beiden Beispiele:

  • The Mars Climate Orbiter space probe failed to land on Sep 23, 1999, because its thruster control software was based on English units while the team responsible for adjusting its trajectory was using the metric system!
     
  • A few months later, the Mars Polar Lander also experienced a setback during its landing. It was still 40 metres above its final landing point when its feet deployed, as expected, but the software interpreted it as an imminent event. As a result, the computer shut down the descent engines, leading to an abrupt crash and total loss of both mission and hardware. System engineers had advised the software developers to not rely on the transient signal from the legs of the lander as they were deploying but, apparently, they failed to document this information in the software specifications.

Quelle: Software Quality Issues, 22 Jun 2015, by Claude Y. Laporte

Beide Beispiele zeigen klar und deutlich, dass keine Anforderung

  • als selbstverständlich gelten
  • oder auch nur undokumentiert bleiben darf.

Es reicht auf keinen Fall, Anforderungen nur mündlich zu kommunizieren — schon allein deswegen nicht, weil später hinzukommende Tester sie dann ja nicht kennen und deswegen auch nicht gezielt verifi­zie­ren werden.
 

Wie oft — und wie dramatisch — Software-Tester versagen


Dass es wirklich höchste Zeit wird, auch die Effektivität von Software-Testern systematisch zu kontrollieren, zeigt eine ganz unglaubliche Sicherheitslücke, die im Februar 2015 in gleich mehreren Tausend per Internet zugänglicher Anwendun­gen entdeckt wurde:

Wie die Computerwoche schrieb, handelte es sich um Konfigurationsfehler die zur Folge hatten, dass — im Prinzip wenigstens — jeder Internet-Nutzer mehrere Millionen Kundendaten nach Name, Adresse, E-Mail und Kreditkartennummer im Internet nicht nur abrufen, sondern auch manipulieren konnte.

Von den zahlreichen Entwicklern dieser vielen Anwendungen war ganz offensicht­lich keinerlei ernsthafter Sicherheitstest durchgeführt worden.

Will da noch jemand behaupten, sie hätten professionell genug gearbeitet?

Und ganz offensichtlich hat auch niemand unter den Verantwortlichen ernsthaft ge­prüft, wie vollständig der Test, für den sie bezahlt hatten, denn nun eigentlich war.

Glaubt die Software-Industrie wirklich, sich derart dilettantisches Vorgehen noch lange leisten zu können?
 

Wie man als CIO Budget für Softwaretest optimal einsetzt


Projekte, die eine Modernisierung unternehmenskritischer Software-Applikationen großer Unternehmen zum Ziel haben, werden größer und größer und verursachen heute Kosten, die gar nicht mehr so selten 3-stellige Millionenhöhe erreichen.

Einen ganz beträchtlichen Teil solcher Ausgaben verursacht der Test der neuen Lösungen: Typischerweise arbeitet daran ein großes Team (in Fällen, die ich zwischen 2003 und 2010 beobachten konnte, waren es bis zu 50 Personen über Jahre hinweg).

Natürlich versucht der CIO des Auftraggebers dann hin und wieder, kosten­günstigere Dienstleister zu finden. Das gängige Verfahren: Es erfolgt eine neue Ausschreibung der Testaufgabe mit dem Ziel, zu prüfen,

  • ob der gegenwärtige Dienstleister nicht allzu teuer oder zu wenig kreativ geworden ist (z.B. deswegen, weil er bestrebt sein wird, mit der Zeit weniger erfahrenes, für ihn billigeres Personal einzusetzen)
     
  • oder ob es konkurrierende Anbieter gibt, die ihn deutlich zu unterbieten in der Lage sind, Offshore-Anbieter etwa.

Sehr oft steht am Ende einer solchen Ausschreibung der Austausch des Anbieters, d.h. der Austausch des gesamtem, großen Teams von Testern und Testmanager.

Das aber kann gefährlich sein, denn

  • erstens geht dabei eine große Menge von Knowhow verloren (die neuen Tester müssen sich ja erst wieder mit der zu testenden Applikationslogik bekannt machen)
     
  • und zweitens ist zunächst noch völlig offen, wie effektiv das neue Team denn nun wirklich arbeiten wird.

Mit anderen Worten:

Die Wahrscheinlichkeit, dass der Befreiungsschlag gelingt, ist ebenso groß wie die Wahrscheinlichkeit, dass er misslingt. Rechnet man die Kosten der notwendigen Einarbeitung des neuen Teams hinzu — Kosten also, die gar nicht anfielen, wenn man beim alten Dienstleister geblieben wäre —, so ist die Wahrschein­lichkeit, dass solcher Wechsel unterm Strich eher Verlust denn Gewinn bedeutet, ziemlich hoch.

Andererseits:

Das Team über Jahre hinweg einfach arbeiten zu lassen, ohne zu versu­chen, die Effektivität des Dienstleisters zu maximieren, wäre ganz sicher auch nicht richtig.

Was also sollte man tun?

Die naheliegenste Lösung ist folgende:

Sobald absehbar ist, dass ein Testteam über längere Zeit hinweg eine gewisse Größe haben muss, sollte man es aufteilen in zwei etwa gleich große Teams, die

  • unter der Regie zueinander konkurrierender Dienstleister
  • unabhängig voneinander an derselben Testaufgabe arbeiten.
  • Wenigstens eines dieser Teams sollte seine Testwerkzeuge selbst wählen dürfen.

Ihre Effektivität sollte einem strengen Monitoring durch den Auftraggeber unter­liegen, so dass der z.B. alle 6 Monate beiden Teams mitteilen kann, wie effektiv jedes von ihnen im Vergleich zum jeweils anderen gearbeitet hat (Effektivität = Kosten dividiert durch die Summe der Gewichte vom Team aufgedeckter Fehler in den zu testenden Applikationen).

Vorteile dieser Lösung:

  • Keiner der beiden Auftragnehmer kann sich leisten, unerfahrende Leute einzusetzen oder ungeeignetes Werkzeug zu nutzen (denn täte er das, würde sofort erkennbar werden, wie seine Effektivität verglichen mit der seines Konkurrenten zurückgeht).
     
  • Sobald eines der beiden Teams deutlich weniger effizient arbeitet als das andere, sieht man, dass es höchste Zeit wird, es auszutauschen.
     
  • Kosten für den Neuaufbau von Knowhow werden so minimiert, und nie ent­steht eine Situation, in der zu wenig gut eingearbeitete Tester verfügbar sind.
     
  • Schon im jeweils eigenen Interesse wird so jedes Team sich optimale Werk­zeuge aussuchen und wird bestrebt sein, das eigene Vorgehen ständig zu überdenken und effektiver zu gestalten.
     
  • Diese Lösung ist kostenneutral.
     
  • Zudem minimiert sie die Wahrscheinlichkeit, dass gelegentlicher Austausch des Dienstleisters zu einer gravierenden Fehlentscheidung wird.

Man bedenke:

Zu beurteilen, wie effektiv Tester arbeiten, ist anders kaum möglich (denn: Die Zahl beim Test gefundener Fehler hängt ja nicht nur davon ab, wie geschickt die Tester vorgehen, sondern auch davon, wie gut die Entwickler gearbeitet haben). Kurz:

Die oben vorgestellte Lösung scheint der einzige Weg zu sein, über den ein CIO erreichen kann, dass die Gelder, mit denen er den Test finanziert, so wirkungsvoll wie nur irgend möglich eingesetzt sind.
 

Software-Qualität – eine oft böse Überraschung


Wer für Software-Entwicklung bezahlt, hält es für selbstverständlich, qualitätsvolle Software zu bekommen. Welch ein Irrtum das sein kann!

Selbst weltweit anerkannte IT-Dienstleister (s.u. Beispiele) liefern hin und wieder absolut unbrauch­bare Software und bescheren so ihren Kunden Verluste in Millionen-Höhe.

Warum nur fühlen sich Software-Entwickler so wenig für die Qualität ihrer Erzeugnisse verantwortlich?

Warum nur sehen sie Qualität so gar nicht als eines ihrer wichtigsten Ziele?

Liegt es daran, dass ihre Auftraggeber Qualität nur allzu pauschal fordern (und denken, sie nicht extra bezahlen zu müssen)?

Traurige Tatsachen sind:

  • Wartbarkeitsaspekte — für Eigentümer und Betreiber der Software extrem wichtig — adressiert kaum jemand: Wie sich die Total Cost of Ownership niedrig halten lässt, diskutieren Entwickler nicht wirklich (sie müsste vom Auftraggeber schon explizit gefordert sein, …).
     
  • Benutzerfreundlichkeit scheint Entwicklern völlig egal (so ergab eine Studie aus 2012).

 

Eine 2001 im Auftrag des deutschen Forschungsministeriums erstellte Studie kam zum Ergebnis: Für Software-Dienstleister ist Qualität ein Fremdwort, und so ist es heute noch:

  • Im Früjahr 2013 bestätigt ein SAP-Team diese Einschätzung ganz unfreiwillig im wirklich übelsten Sinne des Wortes: durch Auslieferung einer absolut unbrauchbaren Neuimplementierung des Payroll Systems der kalifornischen Behörden auf der SAP Plattform (siehe [1], kürzer [CW]).
     
  • Ähnliches war einige Monate früher IBM passiert (siehe [2]). Diesem Team misslang die Neuimplementierung eines Order Management Systems. Man streitet sich jetzt vor Gericht um einen zweistelligen Millionenbetrag.
     
  • Vorher schon hatte IBM in Australien Software abgeliefert, die unbrauchbar war: "The system, which was delivered 20 months after deadline and 300 per cent over budget, led to 70,000 staff in Queensland’s health system being underpaid, overpaid or not paid for months."
     
  • Leider sind das keineswegs die einzigen Beispiele für in den letzten Jahren komplett schiefgelaufene, wirklich große Software-Entwicklungsprojekte. Siehe auch Zahlen dazu, z.B. von 2010.
     
    Man muss sich ernsthaft fragen, ob gängige Software-Entwicklungsmethodik (insbesondere die neue, sog. agile) nicht ganz grundsätzlich nur für Projekte kleiner oder mittlerer Größenordnung funktioniert.

    Wie sonst nämlich wäre es erklärbar, dass man mit den heute zur Verfügung stehenden wunderbaren, kaum noch verbesserungsfähigen Entwick­lungs­werkzeugen an der Neuimplementierung von Anwendungen scheitert, die man vor 30-40 Jahren schon einmal – und damals doch durchaus erfolgreich – geschaffen hatte (!).

    Oder sind vielleicht die Einkäufer schuld, die davon ausgehen, dass der jeweils billigste Anbieter das Projekt schon stemmen werde? Wollen sie Qualität zum Nulltarif?

 

In 2010 schrieben Wissenschaftler der Carnegie Mellon University, die Software-Entwicklungsprozesse untersucht hatten: The software industry is the only modern high-tech industry that ignores quality until test.

Inzwischen aber zeigt sich noch Schlimmeres:

Selbst wirkungsvoller Test gelingt Software-Entwicklern nicht wirklich (siehe etwa [3], [4] und [5] sowie The Healthcare Go Live Debacle).

Wie wenig effektiv Tester bisher sind, spiegelt sich auch wider in Gartners Erkennt­nis: 40% of problems are found by end users.

Wie lange noch — so frage ich — werden Auftraggeber sich das gefallen lassen?

Und insbesondere: Wann endlich werden Software-Entwickler die Konstruktion von Qualität ebenso ernst nehmen, wie das Konstruieren der Software selbst?

Bisher ist das Streben nach Qualität auf Seiten der Entwickler selten mehr als ein Lippenbekenntnis.

Tatsache ist: Wo Termin und Budget eng werden, wird weniger getestet — mit oft schlimmen Folgen (immer für den Auftraggeber, nicht selten auch für den Auftrag­nehmer). Beide Vertragspartner sollten sich dessen bewusst sein und nicht ver­säumen, dem ganz entschieden zu begegnen: Auf jeden Fall weit effektiver als bisher zu beobachten.

Den oft jungen Entwicklern sei gesagt:

Zu glauben, dass sogenanntes agiles Vorgehen die früher übliche, peinlich genaue Dokumentation aller zu entwickelnden Funktionalität überflüssig macht, ist ein ganz gewaltiger Irrtum: Der Wille, praktisch alles, was man produziert, in jedem noch so unfertigen Zustand gerne dem Anwender zu zeigen (damit der sage, wo er was anders haben möchte), mag ja gut gemeint sein, ist aber einfach nur naiv, denn solches Vorgehen überfordert den Anwender – man schiebt ja so nur eigene Verantwortung auf ihn ab.

Kluge Kunden durchschauen das und akzeptieren es nicht.

Vorzugehen, wie im Agilen Manifest gefordert, kann nur gut sein für prototypische Entwicklung in sehr kleinen Teams. Viele der heutigen Entwickler wollen das nicht einsehen. Methodiker, die ihnen Einhalt gebieten, gibt es nicht mehr wirklich. Es fehlt wohl die Einsicht, dass sie zu bezahlen sehr gut angelegtes Geld wäre …

SCRUM-Verfechter, eine spezifische Subklasse der Agilisten, übersehen, dass sich mit täglichen Stand-up-Meetings nur Mikroprozesse steuern lassen — auf keinen Fall aber Großprojekte.

Droht uns eine neue Software-Krise?


Wohl noch nie hat sich einer der weltweit wichtigsten Software-Produzenten der­maßen gründlich blamiert wie eben jetzt die SAP. Was geschah?

Mitte 2006 vergab der Staat Kalifornien ein Projekt, dessen Inhalt es sein sollte,
das damals schon 30 Jahre alte staatliche Payroll System auf SAP-Basis neu zu implementieren.

Solche Neuentwicklung sollte das Problem beseitigen, dass kaum noch Program­mierer zu finden waren, die die alte Technologie gut genug verstanden, volle Funktionsfähigkeit der Anwendung auf Jahre hinaus zu garantieren.

Nachdem der ursprüngliche Auftragnehmer, damals BaringPoint, nach 3 Jahren – pikanterweise erst zum geplanten Projektende-Termin (!) — eingestehen musste, dass man mit einer Neuimplementierung dieser Anwendungs hoffnungslos über­fordert war, wurde das Projekt ein zweites Mal begonnen: jetzt aber, um wirklich sicher zu sein,

  • mit SAP als Auftragnehmer
  • und unter der Nebenbedingung dass zunächst mal in einer Pilotphase nur ein ganz kleiner Teil der Anwendung – weniger als 5 Prozent der gesamten Funktionalität – entwickelt und in Betrieb genommen werden sollte.

Schon diese Pilotphase aber ging so gründlich daneben, dass auch SAP – d.h. der für Systeme dieser Art wohl kompetenteste Entwickler weltweit (!) – im Januar 2013 gefeuert werden musste.

Wie gründlich die SAP versagt hat geht hervor aus einer eben erst (Feb 13, 2013) herausgegebenen Pressemitteilung des State Controller Office (SCO), das als Auftrag­geber fungiert. Man liest dort u.A.:

    One fact is particularly troubling with respect to SAP’s lack of progress:

    The pilot phase only covers 1,300 SCO employees and two bargaining agreements with fairly simple payroll requirements. After eight months and little progress, the SCO cannot responsibly proceed to the second phase and expose thousands more State employees to payroll errors.

    Nor can the SCO have any confidence that SAP can scale the failed system to cover the State’s 240,000 employees, operating out of 160 different departments, under 21 different bargaining units.

    The errors in the SAP system affect everyday lives: Not only have SCO employees been paid too much, or too little, they and their family members also have been denied medical services despite paying for the insurance coverage. Payments to the State’s dental, vision and deferred compensation partners have been incorrect and delivered late. Improper deductions have been taken, payments have been made to the wrong payee, payroll and pensionable wages have been incorrectly calculated, and union deductions incorrectly determined.

    To stabilize payroll for its employees, the SCO is rolling back its 1,300 employees to the legacy system that is currently and reliably paying all other 240,000 State employees.

 
Derzeitiger Projektstand also:

Fast 7 Jahre nach der ersten Auftragsvergabe

  • Ist das ursprüngliche Budget von 70 Mio. USD schon um etwa das 4-fache überschritten,
  • und man ist zurückgeworfen auf den allerersten Schritt (der jetzt darin be­steht, nun schon zum dritten Mal einen geeigneten Auftragnehmer finden zu müssen).

 
Wer jetzt denkt, dieses Beispiel sei ein einmaliger Ausrutscher, also eher nicht typisch, wird durch andere Beispiele schnell eines Besseren belehrt:

  • Beispiel 1: Noch glimpflich abgegangen ist das New York CityTime Projekt, wo es ebenfalls um die Modernisierung eines Payroll Systems ging: The New York CityTime project was planned in 1998 to cost around $63 million and take five years to complete.

    Tatsächlich fertiggestellt wurde es – einer ganz offensichtlich viel zu wenig kompetenten Entwicklungsmannschaft wegen – erst im Sommer 2011 mit einer Überschreitung des ursprünglich geplanten Projektbudgets von sage und schreibe um gut das 12-fache.

  • Beispiel 2: In Australien endete 2010 ein Payroll System Projekt in einer absoluten Katastrophe: "Thousands of nurses were overpaid, underpaid or not paid at all when IBM rolled out its faulty system in March 2010." Mit dafür verantwortlich war absolut unprofessionelles Projektmanagement auf Seiten des Auftraggebers.

    Auch dieses Beispiel ist Beweis dafür, dass Arbeiten für den Entwurf von Software — und ganz besonders auch die für den Test von Software — heute kaum professioneller erledigt werden als noch zu Zeiten der Softwarekrise Ende der 60-iger Jahre.
     

  • Beispiel 3: Im November Ende 2012 kommt es zum Eklat über ein von IBM völlig unprofessionell angegangenes Projekt, in dem der Auftraggeber dem Auftragnehmer (IBM) vor Gericht zerrt mit der expliziten Anschuldigung, er habe zur Entwicklung des unternehmenskritischen Systems inkompetente Entwickler eingesetzt und sich lange Zeit geweigert, das zuzugeben.

    Schließlich hätten sogar IBM-Mitarbeiter das, was dort entstand und in Betrieb genommen wurde, die schlechteste SAP-Implementierung genannt, die sie je gesehen hätten.

    Zum endgültigen Bruch mit dem Auftraggeber (Avantor) kam es, nachdem IBM ihm einer Problembehebung wegen zumuten wollte » to cancel every pending order and reset the entire System in light of pervasive warehouse problems. IBM said this was necessary to discover the root cause of the problem. Ultimately, IBM acknowledged that it had to engage in extensive remedial efforts to redesign and rebuild the System that Avantor hired it to deliver. « (Quelle: Avantors Aussage).

 
Fragen wir uns deswegen:

  • Wie kommt es, dass es so extrem schwierig erscheint, mit der heute zur Verfügung stehenden (sehr ausgereiften) Technologie zu erreichen, was man mit längst überholter doch schon mal erreicht hatte: z.B. funktionstüchtige Payroll oder Order Management Systeme zu bauen?
  • Muss man da nicht glauben, dass moderne Projektteams einfach nicht mehr systematisch genug arbeiten?

 
Dieser schlimme Verdacht liegt wirklich nahe, und Ursache solcher Mängel könnte gut sein, dass junge Software-Entwickler heute glauben, UML, SCRUM und Agiles Vorgehen (missverstanden im Sinne des Agile Manifesto) seien der Weisheit letzter Schluss.

Nur ältere Kollegen — solche mit Erfahrung aus den 80-er Jahren — scheinen zu wissen, dass vor allem systematische, gut pflegbare, stets aktuelle Dokumentation von Anforderung und Lösung das Rückrat erfolgreicher Projekttechnik ist.

Auch sollte man einsehen, dass der berechtigte Wunsch nach agilem Vorgehen (im richtig verstandenen Sinne) sich kaum mit dem heute allgegenwärtigen Wunsch nach Festpreisen verträgt.

Wo Einkäufer sich beharrlich weigern, das einzusehen, steigt das Risiko, am Ende eine wenig funktionsgerechte Lösung zu haben.
 

Die Achillesferse aller Software-Entwickler


Wissenschaftliche Untersuchungen (z.B. eine der Carnegie Mellon University aus 2003) belegen, dass moderne Software, wenn sie in Betrieb genommen wird, i.A. immer noch bis zu fünf Fehler pro 1000 Lines of Code enthält; sprich: etwa 1 Fehler auf je 3 DIN A4 Seiten manuell erstellten Source Codes.

Selbst im besten untersuchten Programm – bestehend aus 10.000.000 Lines of Code – fand sich immer noch 1 Fehler in je 7500 Zeilen. Wirklich vorhanden waren wohl mehr, denn in großen Systemen entdeckt man niemals alle.

Wären mathematische Publikationen auch nur annähernd so fehlerhaft, wäre die Mathematik als Wissenschaft längst in sich zusam­men gebrochen (es baut dort ja Neues stets auf Älterem auf).

Wir sehen: Die Informatik — wenigstens aber ihre Technik zur Qualitätssicherung — steckt heute wohl noch in Kinderschuhen, die vergleichbar sind mit denen, die die Mathematik noch vor Christi Geburt trug.

Auf jeden Fall ist Software heute noch weit davon ent­fernt, so fehlerfrei zu sein, wie die Ergebnisse der Mathematiker das sein möchten (und i.A. auch wirklich sind).

Siehe auch:

 
Dass es wirklich höchste Zeit wird, zeigt eine ganz unglaubliche Sicherheitslücke, die 2015 in gleich mehreren Tausend auf Mongo-DB basierender Anwendungen entdeckt wurde (aber nicht dem Datenbankhersteller anzulasten ist):

Wie die Computerwoche schrieb, handelte es sich um Konfigurationsfehler die zur Folge hatten, dass — im Prinzip wenigstens — jeder Internet-Nutzer mehrere Millionen Kundendaten nach Name, Adresse, E-Mail und Kreditkartennummer im Internet nicht nur abrufen, sondern auch manipulieren konnte.

Von den zahlreichen Entwicklern dieser vielen Anwendungen war ganz offen­sichtlich kein oder viel zu wenig ernsthafter Sicherheitstest durchgeführt worden.

Will da noch jemand behaupten, sie hätten professionell genug gearbeitet?

 

PS: Im Artikel Dogma-driven Development schreibt ein gewisser David Green recht treffend:
 
The trouble is, in this farcical echo chamber of an industry, where the lessons of 40 years ago still haven’t been learnt properly. Where we keep repeating the mistakes of 20 years ago. Of 10 years ago. Of 5 years ago. Of 2 years ago. Of last week. For Christ’s sake people, can we not just learn a little of what’s gone before?

Man ist versucht zu fragen: Warum gestatten Auftraggeber den Software-Entwicklern derart unprofessionell zu arbeiten? Zählt denn wirklich nur, dass sie einen Festpreis einhalten? Warum interessiert die Auftraggeber kaum die abgelieferte Qualität? Fühlt man sich unfähig, sie zu beurteilen?

 

Notwendiges Wissen kompetenter Software-Entwickler


Kompetente Software-Entwickler wissen und beherzigen: