Kommt es zu einer neuen Softwarekrise?

   





D i s k u s s i o n


  Beitrag 1957-18
Erste Anzeichen einer neuen Software-Krise

 
 


Payroll Systeme in Kalifornien und New York zeigen

völlig unerwartete Grenzen moderner Software-Entwicklungs-Methodik



Mitte 2006 vergab der Staat Kalifornien ein Projekt, dessen Inhalt es sein sollte, ein damals schon 30 Jahre altes Payroll System auf SAP-Basis neu zu implementieren.
Solche Neuentwicklung sollte das Problem beseitigen, dass kaum noch Programmierer zu finden waren, die die alte Technologie gut genug verstanden, volle Funktionsfähigkeit der Anwendung auf Jahre hinaus zu garantieren.

Die Kosten für die Neuentwicklung wurden auf 69 Mio. US-Dollar geschätzt,
und nach einer immerhin 3-jährigen Projektlaufzeit sollte das neue System 2009 einsatzfähig sein:

Zitat:
 
BearingPoint Inc. will put in place a new payroll and personnel system for California under a $69 million contract awarded by the state controller's office.

The McLean consulting company will work with SAP Public Services Inc. on an initiative the state calls the 21st Century Project.
The goal is to replace a 30-year-old system with one that is state of the art.

SAP will furnish software, maintenance and training for state employees to run the software, while BearingPoint will adapt SAP's software and implement it in state agencies.

The state selected SAP in April 2005 for the payroll and personnel software, and subsequently picked BearingPoint to handle the implementation. BearingPoint signed the contract in June 2006.

The system is scheduled to be online by November 2007, with full implementation expected by June 2009.


Nachdem sich dann aber 2009 (zum ursprünglich geplanten Projektende) herausstellte, dass BaringPoint mit dem Projekt hoffnungslos überfordert war, hat der Staat Kalifornien das Projekt abgebrochen und es dann erneut direkt an SAP vergeben.

Inzwischen vorsichtig geworden, sollte das Projekt unter dem neuen Auftragnehmer — SAP — in 5 Schritten implementiert werden. Schon der erste von ihnen — die sog. Pilotphase — ging so gründlich daneben, dass auch SAP gefeuert werden musste: Der durch SAP abgelieferte Prototyp versagte völlig, obgleich er doch nur etwa 5% der Gesamtfunktionalität abzudecken hatte:


Der Umfang, in dem selbst SAP versagt hat, macht sprachlos:

Zitat von State Controller John Chiang:
 
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 as requested by SAP 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.


Es ist noch nicht mal klar, ob irgend ein Teil von SAPs Projektergebnis im neuen System Verwendung finden kann:

Zitat von State Controller:
 
On February 8, 2013, the State Controller’s Office (SCO) terminated its contract with SAP as the system integrator for the MyCalPAYS system, the largest payroll modernization effort in the nation.

At the same time, the Secretary of the California Technology Agency (CTA) suspended further work until ... an independent assessment of SAP’s system to determine whether any of SAP’s work can be used in the SCO’s go-forward plan to address the State’s business needs.


Dieses Projekt-Fiasko erinnert an einen ganz ähnlichen Fall in New York, in dem sich IBM fast so überfordert sah, wie SAP oben:

Zitat von März 2011:
 
... the New York CityTime project was planned in 1998 to cost around $63 million and take five years to complete.

It is now (March 2011) estimated to cost some $720 million before it is finished sometime this summer

Zitat von 2012:
 
CityTime originally had a $63 million budget, but costs since skyrocketed astonishingly, with total estimates reportedly reaching $760 million.


An beiden Fällen ist interessant, dass hier lediglich existierende, schon Jahrzehnte alte Systeme neu implementiert werden sollten, und dass
  • im einen Fall gleich 8 Jahre mehr als geplant benötigt wurden (mit 12 mal so hohen Kosten wie geplant),
  • man im anderen aber nach nunmehr 7 Jahren immer noch genau dort steht, wo man begonnen hat (obgleich schon jetzt 254 Mio USD ausgegeben wurden, also schon fast das 4-fache des ursprünglich angesetzten Bugdets).


Wie also kommt es, dass so extrem schwierig erscheint,

mit heutiger Technologie und Methodik zu erreichen, was man mit längst überholter doch schon mal erreicht hatte?



Muss man da nicht glauben, dass moderne Projektteams nicht mehr systematisch genug arbeiten?


Ein drittes Beispiel, dort mit IBM als Hauptverantwortlichen, scheint diesen Verdacht zu bestätigen.

 

Wie die Zusammenstellung 10 biggest ERP Software Failures of 2011 zeigt, sind solche Beispiele nicht einfach nur seltene Ausnahmen.

 

 Beitrag 0-145
Warum SCRUM — und undurchdachtes "Agile" — uns in den Abgrund führen

 
 

 
Was SCRUM
 
— von nur wenigen Ausnahmen abgesehen —
 
verdammenswert macht

 
 
In Reaktion auf die Ende der 60-er Jahre eingetretene Software-Krise kam es — zur immerhin ganze drei Jahrzehnte währenden — Blütezeit des Software Engineerings.
 
Ich bin heute noch dankbar, dass ich sie miterleben durfte als jemand, der einige ihrer Pioneere gut gekannt hat: Insbesondere F.L. Bauer und Ernst Denert.
 
Wofür ich sie — aber auch Parnas, Dijkstra und Boehm — heute immer noch bewundere, ist, welche unglaublich große, wirklich durchschlagende Wirkung sie mit ihren Lösungsvorschlägen erzielten:
 
    Jede dieser fünf Personen hat eine wichtige Schlüsselidee erfolgreichen Software Engineerings in die Welt gesetzt bzw. wurde — wie z.B. Ernst Denert —
    nicht müde, sie zu propagieren.
     
    Welch gewaltige, nachhaltige Wirkung gerade Denert damit erzielt hat, das Prinzip der Datenabstraktion auch in der Praxis hoch zu halten, konnte ich als damaliger Mitarbeiter von Softlab hautnah miterleben: Denert war nur etwa 5 Jahre für Softlab tätig (so etwa 1975-1980), hat jene Firma durch sein Wirken
    aber auf die richtige technologische Schiene gesetzt, was bewirkt hat, dass sie noch bis hin zur Jahrtausendwende deutlich erkennbar davon profitiert hat — natürlich auch in Mark und Pfennig, wie man so schön sagt.
     
    Denerts Prinzip » Die beste Praxis ist eine gute Theorie « fand und finde ich immer wieder bestätigt.

 
Gegeben also die großen Methodiker der Jahre 1965-2000, war es kaum zu verstehen, dass keiner von ihnen — ausgenommen vielleicht Tom Gilb — irgendwelche Versuche unternahm, die beispiellose Naivität des Agilen Manifests und all derer, die es wörtlich nehmen, als  p u r e s  G i f t  zu identifizieren.

     
    Sie alle haben tatenlos — und wohl sprachlos vor Verwunderung — zugesehen, wie alles, was sie an methodischem Fortschritt über gut 30 Jahre hinweg erarbeitet hatten, plötzlich unter Berufung auf das Agile Manifest als nicht weiter akzeptabel erklärt wurde.
     
    Unangetastet blieb nur, was schon eingeflossen war in die Konzepte moderner Programmiersprachen.
     
    Erst heute, etwa 20 Jahre nachdem die Agilisten, die Erfinder von SCRUM und die vielen Trainer, die "Agile" und SCRUM zu propagieren als ihre persönliche Goldgrube entdeckt haben, wird so manchem langsam klar, in welch beispiellose Sackgasse uns die unausgegorenen Ratschläge der Agilisten bereits geführt haben:

    Die agile Bewegung nämlich hat bewirkt, dass ein Großteil dessen, was in der Blütezeit des Software Engineerings an methodischem Fortschritt erarbeitet worden war — insbesondere das Wasserfallmodell — heute unter jungen Software-Entwicklern geradezu als  A n t i p a t t e r n  gilt.
     
    Ihnen wird nicht mehr klar, dass Kritik am Wasserfallmodell sich nicht auf das Modell selbst bezieht, sondern lediglich auf seine allzu starre Anwendung, die dann gegeben ist, wenn man sich weigert, einmal abgenommene Teilergebnisse bei Bedarf noch  v o r  Projektende zu revidieren.
     
    Die durch die agile Bewegung in ihrer Naivität verursachte "Entsorgung" methodischen Knowhows geht so weit, dass selbst die Vertreter der jungen Generation, die SCRUM inzwischen als  k o n t r a p r o d u k t i v  erkannt haben — der niederländische Informatik-Dozent Erik Meijer etwa, der mehrfach für seine gute Arbeit als Systemarchitekt bei Microsoft ausgezeichnet wurde —, heute genau das als Abhilfe propagieren, was Mitte der 60-er Jahre die damalige Softwarekrise ausgelöst hatte: der Glaube nämlich, dass es genüge und wünschenswert sei, einfach nur Code zu schreiben.

 
Michael O. Church — heute Manager von Entwicklungsteams bei Google — hat es geschafft, treffend zu charakterisieren, was speziell SCRUM — von seltenen Notfallsituationen mal abgesehen —  v e r d a m m e n s w e r t  macht. Er schreibt (im Juni 2015):
 
    So what are Scrum and “Agile”? I could get into the different kinds of meetings (“retrospective” and “backlog grooming” and “planning”) or the theory, but the fundamental unifying trait is violent transparency, often one-sided. Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties.
     
    Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high). Agile eliminates the concept of ownership and treats programmers as interchangeable, commoditized components.
     
    In addition to being infantilizing and repellent, Scrum induces needless anxiety about microfluctuations in one’s own productivity. The violent transparency means that, in theory, each person’s hour-by-hour fluctuations are globally visible– and for no good reason, because there’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. For people with anxiety or mood disorders, who generally perform well when measured on average long-term productivity, but who tend to be most sensitive to invasions of privacy, this is outright discriminatory.

 
Seine ausführliche, das Problem genau identifizierende Analyse schließt mit der Feststellung:
    It’s time for most of "Agile" and especially Scrum to die. These aren’t just bad ideas. They’re more dangerous than that, because there’s a generation of software engineers who are absorbing them without knowing any better. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and "user stories" are how things have always been done. This ought to be prevented; the future integrity of our industry may rely on it. "Agile" is a bucket of nonsense that has nothing to do with programming and certainly nothing to do with computer science, and it ought to be tossed back into the muck from which it came.


 

 Beitrag 0-149
Microservices: The most extreme SOA Solution

 
 

 
What are Microservices?

 
 
The concept of microservices is probably best defined here or by Martin Fowler, or at any of the first google results for "microservices".
 
Mircoservices are separately deployable modules that communicate with each other in order to complete a business goal, and each microservice is limited to just a small, well-defined scope:
 
Product purchasing is one microservice, user registration is another one, "Current Promotions" may be a third one, and so on.
 
But Martin Fowler also says:

 
 
Don’t even consider microservices unless you have a system that’s too complex to manage as one piece.
 
 
The majority of software systems should be built as a single monolithic application.
 
If you pay attention to good modularity within that monolith, this may be enough.


 
 
Universally, if you are sure that the network and coordination overhead of microservices will be negligible compared to the amount of work being done and the flexibility gained, then microservices are a valid approach. But that may be rare. Martin Fowler talks about complexity vs productivity, so, in theory, if you know in advance how complex your project is going to be, you  m a y  have a valid microservices use case.
 
Separating a piece of functionality into a service of its own and communicating with it through web services should not be something that deserves so much attention. But apparently we have to say » No, it’s not for every project « and » Yes, the approach is not dumb by itself, there are cases when it is useful «.

 

 Beitrag 0-Agile
Agilität ist unverzichtbar — in Form vom "Agile" und SCRUM aber sicher gefährlich

 
 

 
Über falsch verstandene "Agile" Methodik

 
 
Wer mich kennt der weiß:
 
Ich bin ein erklärter Gegner der im 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 darf 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 — das zählt wirklich — aus negativer Erfahrung heraus zu dieser Einstellung kamen:
 
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,

m u s s t e n  irgendwann zu einer Gegenreaktion führen. Sie kam in Form der Agilen Bewegung, war aber nicht durch entsprechende Forschung unterstützt, und hat daher zu einem geradezu lächerlichen Modell geführt, desssen Aushängeschild sich SCRUM nennt.
 
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 ...
 
 
 
Gebhard Greiter, Jan 2016


 

 Beitrag 0-182
What is — and how long can you be — a competent Software Architect?

 
 

 
What is a Software Architect?

 
 
I agree with the definition presented in Every Developer Should Be an Architect where we read:
 
Consider programmer/software engineer versus architect as a study in contrasts (I used this post by Simon Brown as a research point for what people perceive to be the differences between architects and developers).
     
  • Focus scope: Programmers focus on details while architects focus on "the big picture".
     
  • Leadership: Programmers are led, architects lead.
     
  • Seniority: Architects have been doing it longer than programmers.
     
  • Cachet: Architects are important visionaries while programmers do relative grunt work.
     
  • Tech Selection: Architects choose while programmers live with the choices.
     
  • Skill: Architects are more technically skilled than most programmers.
     
  • Organizational interaction: architects deal more with “the business” in meetings than programmers.
     
  • Pay: Architects make more than programmers.
     
  • Value: Architects understand why an architect is more valuable than a programmer.

This is how the industry at large perceives this distinction:
 
Architects are more tenured, more important, more valuable — they are technical people in high demand, but are often seen as being too important to do the things that earned them their stripe (writing code).
 
This is why compentent architects have to fight for time to keep up to date:
 
 
As soon as they do not write code anymore ( prototyping new solutions ),
 
they will no longer be competent architects (!).

 
 
Erik Dietrich & Gebh. Greiter, Jan 2016


 

 Beitrag 0-183
Why an Application Architect is more that just a competent Requirements Manager (Product Owner)

 
 

 
What is a compentent Solution Architect?

 
 
He/she should be
     
  • a competent Requirements Manager
     
  • as well as
     
    • a creative Software (Black Box) Architect
    • and end-to-end test designer.

Testability of an application, e.g., is something a perfect solution architect will have to guarantee.
 
Maintainability of the solution to be created — until far into the future — is important as well.
 
 
For this to achieve, the architect is to establish
     
  • a process to garantee an always up to date specification of requiremments as well as black box interface design,
     
    Both documents are to be implemented in a form showing clearly all the differences between the implemented and the not yet implemented version of the requirements and as well as the black box interface of the system. [ New text shown in red might be a suitable soltion. ]
     
  • a process to guarantee an always up to date regression test suite as well as nice, complete documentaion of the results of each end-to-end test run,
     
  • a bug tracking system with suitable reporting functionality,
     
  • documentation of all budget consumed so far for what purpose (in order to have reliable data on which cost estimates for the implementation of not yet implemented, though later on required changes or functionality can be based on).

 
Note: Creating documents showing only the difference between two versions of the system is definitely NOT a good thing (because then, to get a complete picture, readers will always have to consult documentaion of all the versions implemented so far.

 

  Beitrag 2027-8
Zur Fehlerdichte in durchaus brauchbarer Software

 
 
Bauhof aus 2027-6:
Grtgrt aus 2027-5:
 
Für beide Arten von Fehlern gilt, dass hinreichend ausführlicher Test sie entdeckt haben sollte, so dass man sie beseitigen konnte, noch bevor das Programm dem Anwender übergeben wurde.

Hallo Grtgrt, ...

Vor langer Zeit habe ich mal gelesen, dass die vollkommene Fehlerfreiheit einer hinreichend komplexen Software niemals bewiesen werden kann. Ist dir das nicht bekannt?


Ja, Eugen, das ist mir bekannt.

Und das ist schon allein deswegen so, weil die SOLL-Funktionalität gegebener Software i.A. gar nicht bis ins allerletzte Detail hinein vorweg definiert wurde (jedenfalls nicht hinsichtlich von Details, die man zunächst als nicht wichtig erachtet hat).

Aber ich schrieb ja auch "Für beide Arten von Fehlern gilt, dass hinreichend ausführlicher Test sie entdeckt haben  s o l l t e  ..." (womit dann klar sein sollte, dass es durchaus Fehler geben kann, die man nicht entdeckt  h a t ... Es werden i.A. aber nur wenige sein, oder solche, die ganz selten auftreten, so dass man mit ihnen leben kann).

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 in den besten aller je untersuchten (größeren) Programme fand sich immer noch 1 Fehler in je 7500 Zeilen Code (durchschnittlich).

Beispiele von anderer Seite bestätigen das: Als Windows 2000 auf den Markt kam, enthielt sein Code — nach Microsofts eigener Schätzung — etwa ein wirkliches, aber zu dem Zeitpunkt noch gar nicht genau unter­suchtes Problem in je 1000 Lines of Code. Dennoch war Windows 2000 ein wirklich brauchbares System.


Gruß, grtgrt
 

 Beitrag 0-195
Software als ernst zu nehmende Gefahr

 
 

 
Software macht angreifbar

 
 
Der internationale Zahlungsverkehr zwischen Banken wird über Swift abgewickelt: ein Softwaresystem, welches weltweit etwa 2000 Mal installiert ist. Zentralbanken, Geschäftsbanken und Investmentfirmen nutzen es.
 
Lange galt Swift als sicher. Im Februar 2016 aber gelang es Cyber-Dieben per Swift 81 Mio Dollar von der Zentralbank in Bangladesh zu erbeuten (genauer: unberechtigterweise auf ein philippinisches Konto zu überweisen, von der das Geld dann weiter an Spielkasinos floß).
 
Diese Angreifer hatten eigentlich Zahlungen in Höhe von einer Milliarde Euro angewiesen. Doch ein Überweisungsauftrag, mit dem das Gros des Geldes transferiert werden sollte, war offenbar adressiert an eine "Shalika Fandation". Nur dieser Rechtschreibfehler im englischen Wort foundation (Stiftung) machte Mitarbeiter bei der Deutschen Bank misstrauisch. Ihre Anfrage bei der Zentralbank in Bangladesh hat den Angriff dann auffliegen lassen.
 
Die Behörden in Bangladesh gehen davon aus, dass die Hacker in die Computer der Notenbank eindrangen und sich so Zugang zu deren Swift-Installation verschafft haben.
 
Verdacht hatte man wohl schon vorher geschöpft, doch die Betrügersoftware verwischte die Spuren, so dass lange niemand etwas beweisen konnte. Über die Schadenshöhe insgesamt ist nichts bekannt.
 
 
Dieser Diebstahl beweist erneut die wachsende Gefahr von Hackerangriffen in der Bankenbranche. So gab die russische IT-Sicherheitsfirma Kaspersky Lab in 2015 bekannt, dass Cyberkriminelle innerhalb von zwei Jahren rund eine  M i l l i a r d e  Dollar von weltweit etwa hundert Geldhäusern gestohlen hätten. Sie hätten sich Zugang zu internen Netzwerken verschafft und so Geldautomaten manipuliert. (Quelle: fab/Reuters)
 
 
Ganz allgemein gilt:
     
  • Die Zahl gezielter Hacker-Attacken hat weltweit schon die Jahre vorher stark zugenommen. So haben etwa 2007 Cyberangriffe gegen Banken, Ministerien, das Parlament und die Rundfunkanstalten ganz Estland lahmgelegt.
     
    Das Netzwerk des Deutschen Bundestages ist 2015 gehackt worden — es hat Wochen gedauert, es neu zu installieren.

     
  • Aber auch kleine Firmen sind ernsthaft bedroht: Nach Aussage von BDI-Präsident Ulrich Grillo (im April 2016) ist inzwischen schon etwa jedes zweite Unternehmen attackiert worden — in 3 von 4 Fällen sei der Schaden groß bis existenzgefährdend gewesen.
     
    Nicht selten ging es um Sabotage und Spionage. Selbst Information über Kontakte, Organisationsstrukturen, Zulieferer und Mitarbeiter können für Angreifer großen Wert haben.

 
Der Gefahr zu begegnen, haben sich die großen deutschen Wirtschaftsverbände mit den Sicherheitsbehörden verbündet und die Initiative Wirtschaftsschutz ins Leben gerufen. Sie informiert und berät.
 
 
Quelle: SZ vom 27.4.2016, Wirtschaftsteil

 
 
Lies auch:
  • Folgenreiche Cyberangriffe auf Unternehmen — enorm hoher Schaden, Angreifer oft unbekannt
     
    Anfang Juli 2016 wurde ein Hacker-Angriff auf die US-Fastfood-Kette Wendy’s bekannt. Auf den Kassensystemen wurde Malware gefunden – zunächst war von weniger als 300 betroffenen Filialen die Rede, später von bis zu 1000. Wie sich dann herausstellte, waren die Malware-Attacken schon seit Herbst 2015 im Gange.