Insgesamt: Wie werden wir Altsysteme warten? [geschlossen]

NEW YORK - Mit einer Explosion, die Wolkenkratzer zum Zittern brachte, sendete eine 83-jährige Dampfleitung die eindringliche Botschaft, dass die kilometerlangen Röhren, Drähte und Eisen unter New York und anderen US-Städten älter werden und gefährlich instabil werden könnten.

Juli 2007 Geschichte über eine Dampfstoßleitung in Manhattan

Wir haben von Softwarefäule und technischen Schulden gehört .

Und wir haben von Leuten wie:

• "Onkel Bob" Martin - Der uns vor " den Folgen eines Chaos " gewarnt hat .
• Michael C. Feathers - Wer uns Führung für gab ‚Effektives Arbeiten mit Legacy - Code‘ .

Die Software-Entwickler sind sich dieser Probleme also durchaus bewusst.

Ich bin jedoch der Meinung, dass unsere gesamte Gesellschaft nicht versteht, wie diese Probleme die Arbeitssysteme und -anwendungen beeinträchtigen können.

Wie Steve McConnell feststellt :

... Im Gegensatz zu Finanzschulden sind technische Schulden weitaus weniger sichtbar, sodass es für die Menschen einfacher ist, sie zu ignorieren.

Wenn dies zutrifft und ich glaube, dass dies zutrifft, befürchte ich, dass Regierungen und Unternehmen die regelmäßige Wartung und Verstärkung von Hackern verschieben, bis es zu spät ist. [Ähnlich wie NYC und die Dampfleitungen.]

Meine Frage:

• Gibt es eine Möglichkeit, das Softwareäquivalent von NYC und den Dampfleitungen zu umgehen?

Ein Hauptproblem bei der Wartung älterer Systeme ist der Mangel an Personen, die a) mit diesen Systemen auf dem neuesten Stand sind und b) bereit sind, sie weiterhin zu warten.

Ich habe kürzlich eine ähnliche Frage gestellt, ob jüngere Programmierer überhaupt an Mainframes interessiert sind. Der Konsens neigte sich zu Nr.

Die Aufrechterhaltung von Altsystemen wird als Karriereselbstmord angesehen. In vielen Unternehmen, in denen es auf Trägheit ankommt, wird nur wenig in die Schulung des Personals investiert, um auf diesen Systemen zu bleiben, was zu einzelnen Fehlerquellen auf der Personalseite führt. Viele Leute, die ich kenne und die an ähnlichen Systemen arbeiten, suchen nach Wegen, weil sie keine langfristige Zukunft in den Systemen sehen und nur berufliche Nachteile sehen.

In einigen Branchen können Vorschriften zur Wartung von Daten ein Schlüsselfaktor sein, der sicherstellt, dass ältere Systeme angemessen überwacht werden. Dies ist insbesondere das Problem in der Finanzbranche, denke ich. Diese Regelungen sind - soweit mir bekannt ist - in der Regel zeitlich begrenzt.

Ich denke jedoch, dass in der Praxis Folgendes passieren wird:

Es wird einen Punkt in der Grafik geben, an dem die Kosten für die Umstellung auf ein moderneres System, mit dem Sie die Nachteile eines Altsystems umgehen können, unter die Kosten für die Wartung des Altsystems fallen, weil es billiger ist.

IBM vertreibt derzeit viele Mainframes und arbeitet intensiv daran, dass die großen Maschinen nicht die jüngeren Profis ausschließen. Aber ich denke, es ist zu diesem Zeitpunkt nicht genug. Sie haben einige Alleinstellungsmerkmale in Bezug auf den CO2-Fußabdruck und die tatsächliche Verarbeitungsleistung.

Für jede Person, die einen IBM-Mainframe kauft, weil Sie Linux darauf ausführen können, ist der Stromverbrauch geringer und die Effizienz hoch. Es gibt mehrere Personen, die sich für eine Serverfarm entscheiden, da sie mit dieser Welt besser vertraut sind und viele weitere Programmierer.

Letztendlich hängt vieles von der Branche ab. Ich arbeite in einer bestimmten Branche, die seit Jahren sehr stark von Mainframes abhängig ist und die immer noch weit verbreitet ist. Aber gehostete Lösungen werden immer beliebter, was die Konsolidierung von Kompetenzen in größeren Unternehmen ermöglicht - dies beseitigt einige der Probleme, mit denen einzelne Unternehmen in Bezug auf Fehlerquellen konfrontiert sind - und einige Anbieter setzen sehr stark auf nicht auf Mainframes basierende Lösungen für die Probleme in dieser Branche inhärent.

Zusammenfassend sage ich also, dass es im Großen und Ganzen zu einer Migration von Altsystemen kommen wird, sobald ein wirtschaftlicher Punkt der Instandhaltung im Vergleich zur Migration zugunsten der Migration fällt. Es wird jedoch für viele Leute weitgehend unsichtbar sein, weil es nicht neu und funky ist und kein sehr öffentliches Gesicht hat, wie es ein Next-Big-Ding tut. Diese Migration kann zu Dienstanbietern oder zu neueren Technologien führen (insbesondere dort, wo die Dienstanbieter direkt betroffen sind).

Ich habe - insbesondere in Netzwerken - die Erfahrung gemacht, dass die Abhängigkeit von Altsystemen aufgehoben werden muss.

Die meisten Unternehmen kennen die technischen Schulden bereits nicht und bemerken nicht einmal, dass die Dinge schlecht sind, bis sie buchstäblich zusammenbrechen und in Konkurs gehen (falls es jemals soweit sein sollte). Ich habe es tatsächlich gesehendas passierte und es war nicht schön; Was es noch schlimmer machte, war die Tatsache, dass ich wiederholt versuchte, die Geschäftsinhaber auf die zunehmende technische Verschuldung aufmerksam zu machen, und dass sie behoben werden musste. Jedes Mal wurde sie abgelehnt, weil ich nicht bereit war, die erforderliche Zeit und die erforderlichen Ressourcen für die Behebung aufzuwenden es. Das Endergebnis war, dass das System nach mehr als 10 Jahren endgültig katastrophal ausfiel (nachdem ich weg war) und sie sich nicht erholen konnten und ihr Geschäft aufgaben, weil sie zu dumm waren, in diesen zehn Jahren zu realisieren, dass sie ein bisschen Geld ausgaben Das Problem zu beheben wäre besser gewesen, als es komplett zu ignorieren. Ich konnte mich stundenlang über die absurde Dummheit dieser Firma austoben, und was mich am meisten schmerzte, war, dass ich es hätte vermeiden können, wenn die Eigentümer es nicht getan hätten Nur um schnell Geld zu machen, indem du alles andere komplett abschneidest.

Es ist wahnsinnig schwierig, einem Unternehmen zu sagen, ob seine Systeme schlecht geschrieben sind und eine gründliche Umgestaltung erfordern (wenn nicht eine vollständige Umschreibung, was normalerweise der Fall ist , weil es so schlecht ist). Meistens schießen sie Sie einfach nieder, selbst wenn Sie sie warnen, dass es schwierig ist, Änderungen vorzunehmen oder neue Funktionen hinzuzufügen (ich meine, der richtige Weg, nicht einfach mehr Mist auf den Stapel zu schichten), oder betrachten Sie sogar als einen Beeinträchtigung des Geschäfts, da Sie Probleme mit dem System in seinem aktuellen Zustand sehen.

Ich bin ehrlich gesagt zu dem Schluss gekommen, dass es ein verlorener Kampf ist, der es nicht wert ist, gekämpft zu werden. Die Leute, die klug genug sind, um über technische Schulden Bescheid zu wissen, müssen nicht zweimal darüber informiert werden und sind sich der Gefahren von Anfang an bewusst, und alle anderen hören auf keinen Grund und keine Warnung, bis es sowieso zu spät ist. Die beste (und natürlich unrealistischste) Option wäre, die natürliche Auslese in Gang zu setzen und die Unwissenden aussterben zu lassen, wobei nur die Intelligenten übrig bleiben. Ich kenne keine bodenständigere Art, damit umzugehen, weil alles, was ich in der Vergangenheit persönlich ausprobiert habe, entweder völlig ignoriert wurde, meinen Wert in den Augen des Unternehmens minderte (weil ich mich beschwerte) oder sogar führte zu meiner Kündigung, weil ich mich "zu sehr darauf konzentrierte", das zu reparieren, was nicht stimmt gebrochen und niemand anderes hatte den richtigen Geisteszustand, um zu sehen, dass es gebrochen war.

Die kilometerlangen Röhren, Drähte und Eisen unter New York und anderen US-Städten werden älter und könnten gefährlich instabil werden.

Für die Anekdote wurde das gleiche Argument im 16. und 17. Jahrhundert in Paris vorgebracht. Darunter waren so viele Löcher und Tunnel gegraben worden (zusätzlich zu den natürlichen Löchern aufgrund der Geologie des Gebiets), dass ein gelegentliches Gebäude zusammenbrach.

Bis ganze Stadtblöcke in den Boden fielen, wurden Anweisungen gegeben, um die nicht benötigten Löcher und Tunnel mit Kies und Knochen zu füllen (sie hatten auch überfüllte Friedhofsprobleme). So überlebte die Stadt, bis der Beton erfunden wurde.

Mein Punkt hier ist, dass viele Organisationen dazu neigen, auf die letzte Minute zu warten, um Software zu warten, aber Programmierer (wie Bauingenieure) erledigen den Job genauso schnell und gut.

Wir haben den Y2k-Bug überlebt. Der Y2036-Fehler wird viele Unternehmen dazu zwingen, ihre Hardware und Software zu aktualisieren. Die Welt könnte 2012 untergehen. Aber Informatiker sind keine Soziologen oder Literaturkritiker .

Oh, und wie das Sprichwort in der Zwischenzeit sagt: Schreiben Sie Code, als wäre der nächste Betreuer ein bösartiger Psychopath, der weiß, wo Sie leben.

Ich vergesse, was betrachten wir heutzutage als Legacy-Code? Code des letzten Jahres, Code des letzten Jahrzehnts oder Code des letzten Jahrhunderts?

Geld treibt das Gespräch um die Wartung von Altsystemen. Technische Schulden nehmen ihre Form als erhöhte Kosten für die Änderung des Systems an.

Ich habe mit schlecht gestalteten und intelligent gestalteten Systemen gearbeitet. Interessant ist, dass die Kosten für die Wartung nicht so stark variieren. Die größten Probleme sind falsche Architekturen für die aktuelle Verwendung, die normalerweise bei Skalierungsproblemen auftreten oder wenn eine größere Änderung gewünscht wird. Es ist nicht einfach, einen größeren Codebereich von Single-Threaded zu Multi-Threaded zu konvertieren.

Die größten Probleme, die ich habe, sind die verwendeten Entwicklungssprachen. Ältere Systeme werden in Sprachen geschrieben, die heutzutage weniger populär sind, sodass Sie entweder mehr trainieren oder mehr erfahrene (teure) und seltene Ressourcen einstellen müssen. In beiden Fällen fällt es Ihnen aufgrund des kleineren Pools schwer, qualifizierte Mitarbeiter zu finden, die in der Regel ebenso viele Probleme wie Lösungen aufwerfen.

Was das versprochene Umschreiben betrifft, rechtfertigen die meisten Systeme, die große Investitionen getätigt haben, kein Umschreiben. Es ist erstaunlich, wie lange Software noch funktioniert und verbessert werden kann. Hardware-Änderungen (einige Systeme, die meine Firma unterstützt, verwenden spezielle Hardware) sind in der Regel unser größtes Problem. Die Verbesserungsmöglichkeiten sind häufig nur durch die Mechanismen begrenzt, mit denen Legacy-Code in neue Funktionen integriert werden kann.

Das ist schon ein großes Problem. Und es zeigt keine Anzeichen einer Veränderung.

In den 60er und 70er Jahren gingen große Institutionen aller Art von der Buchhaltung auf Papier zur Buchhaltung auf Computersystemen über. Überwiegend entschieden sie sich für COBOL. Die meisten verwenden immer noch aktualisierte Versionen dieser COBOL-Systeme. Eine Statistik hierzu finden Sie unter http://cis.hfcc.edu/faq/cobol

Von Zeit zu Zeit erhalten wir zufällige Erinnerungen daran, beispielsweise als Arnold Schwarzenegger vor ein paar Jahren entdeckte, dass er die Bezahlung von 200.000 Staatsangestellten nicht einfach kürzen konnte, ohne vorher 6 Monate Entwicklungszeit zu haben (siehe http: //www.infoworld). de / d / developer-world / californias-cobol-conundrum-067 zur Überprüfung).

Angesichts der Wechselrisiken ist ein Wechsel dieser Systeme nur schwer zu rechtfertigen. Je. Das war für mein ganzes Leben Realität. Aber ich sehe keinen Grund dafür, dass sich dies im Leben meiner Kinder ändert. Oder das Leben ihrer Kinder.

Ich habe Freunde, die Code gepflegt haben, der älter ist als sie. Ich habe eine Freundin, die 30 Jahre, nachdem sie das erste Mal dort gearbeitet hatte, zu einem Unternehmen zurückgekehrt ist und festgestellt hat, dass ihre Programme immer noch unverändert in einer Sprache laufen, an die sie sich nicht einmal erinnern konnte!

Lassen Sie mich mit einer wahren Begebenheit abschließen, was beides passieren kann.

In den 1970er Jahren ein Unternehmenwurde gegründet, um einen Online-Markt für Händler bereitzustellen. Der PDP-11 war ein gutes Preis-Leistungs-Verhältnis für sie, also entschieden sie sich dafür. Sie haben die Leistungsgrenzen einer Maschine erweitert und ihr System in einer hochoptimierten PDP-11-Baugruppe geschrieben. Einige Jahre später wurde der PDP-11 nicht mehr verkauft. Das Geschäft lief jedoch sehr gut, die Maschinen hielten an und gebrauchte Ersatzteile waren leicht zu beschaffen. Sie behielten ihre Plattform. Einige Jahre später wurde es schwieriger, Ersatz zu bekommen. Es wurde ein Großprojekt durchgeführt, um die Handelsplattform zu ersetzen. Es ging schief. Sie versuchten es erneut. Und wieder gescheitert. Eine Hauptursache für das Versagen war, dass niemand wusste, wie das Handelssystem funktionierte, und niemand mehr die PDP-11-Baugruppe lesen konnte. Dann schlug die Erlösung ein. Jemand hat einen PDP-11-Assembler erstellt, der unter Linux ausgeführt wird.

So gingen im Jahr 2000 Geschäfte im Wert von einer Milliarde Dollar / Jahr über eine Ethernet-Decnet-Brücke an Linux-Maschinen, um PDP-11-Maschinen zu emulieren, die den Handel auf einem Softwaresystem ausführten, das in hochoptimiertem PDP-Format geschrieben war. 11 Versammlung. Für Geschwindigkeit.

Ich hatte in den letzten zehn Jahren keine Verbindung zu dieser Firma. Ich kann Ihnen also nicht sagen, ob sie immer noch auf emulierten PDP-11 laufen. Ich weiß, dass die Dezimalisierung ihre Ränder schmerzhaft drückte, und sie hatten noch eine weitere Anstrengung, um zu migrieren. (Ich habe die Geschichte nur erfahren, weil ich mehrere Personen interviewt habe, die von dort entlassen worden waren, und gefragt habe, was passiert ist.) Bei früheren Fehlern würde ich es jedoch besser geben als nur zu vermuten, dass sie dieses System nicht erfolgreich ersetzt haben.

Klingt aus Anwendersicht nach einem sehr echten Anliegen. Damit die Fäulnis verzögert oder besser vermieden wird, muss die betreffende Software frei von Fesseln sein. Die Herausgeber sollten den Quellcode freigegeben haben oder damit befasst sein, die Quellen zu warten und zu aktualisieren, bis der letzte Benutzer ihn nicht mehr verwendet. Andernfalls besteht eine sehr gute Chance, dass sie aufgrund ähnlicher Fäulnisse in der Geschäftswelt aus dem Geschäft ausscheiden und die Software daher für die Fäulnisse uneingeschränkt offen lassen.

Das heißt, die Laufzeit von Software-Urheberrechten und die Beschränkung von Lizenzen sollten sehr kurz sein, wobei am Ende die Software und ihre Codebasis gemeinfrei werden und dort verbleiben. Dies ermöglicht es dem Benutzer, die Quellen weiter zu aktualisieren oder jemanden damit zu beauftragen, wodurch die Fäulnisse verzögert und / oder vermieden werden.

Wenn Sie ein wenig offen für die Idee freier Software sind, können Sie Ihre Programme unter einer freien Lizenz wie der AGPL oder der GPL oder anderen freien Softwarelizenzen schreiben. Wenn die Quellen einer Software aus irgendeinem Grund kein Interesse mehr an den Entwicklern haben, diese zu verbessern, kannibalisiert sich die Quellenbasis und gewinnt neues Leben. Pakete im Debian-Betriebssystem tendieren, soweit ich gesehen habe, dazu, diesem Lebenszyklus zu folgen.

Nachdem ich eine Vielzahl von Regierungs- und Privatanwendungen unterstützt habe, würde ich sagen, dass sich die meisten Unternehmen und zumindest die US-Regierung der Gefahren bewusst sind, Code verrotten zu lassen und nicht über die neuesten Sicherheitstrends auf dem Laufenden zu bleiben.

Wir müssen unsere Software regelmäßig für verschiedene Anfälligkeiten zertifizieren lassen, und die meisten staatlichen elektronischen Systeme, auch alte, werden regelmäßig aktualisiert, um ihre Sicherheit zu gewährleisten.

Natürlich gibt es Ausnahmen und Hacker sind immer in Bewegung, aber im Großen und Ganzen sind sich die Leute ziemlich bewusst, dass man etwas nicht einfach rausschmeißen und es nie wieder anfassen kann.

Achtung: Dies wird ein bisschen Freiform sein ...

Ich glaube, es gibt zwei Möglichkeiten, Ihre Besorgnis zu betrachten.

Wenn Sie daran denken, haben einige Space Shuttles und Satelliten denselben Code ausgeführt, mit dem sie ursprünglich gestartet wurden. Auf der anderen Seite wurden einige entwickelt, um aktualisiert zu werden, auch wenn sie (sehr) abgelegen sind.

Was zählt, ist die Umwelt. Solange Sie die Umgebung nicht ändern, wird Ihr Code natürlich nicht veraltet sein. In diesem Fall existiert Code rot nicht wirklich: Der Code selbst (oder die erzeugte Binärdatei) kann nicht rotieren. Es kann brechen, wenn Sie es nur aus einem völlig anderen Blickwinkel angreifen. Es ist nicht so, dass es verfault, es ist so, dass es sich nicht an seine Umgebung anpasst. Betrachten Sie es als ein evolutionäres Problem.

Aber unsere Umwelt verändert sich. Und irgendwie ist der Schlüssel zu Ihrem Problem auch die Lösung. Unsere Umgebung ändert sich so schnell, dass wir heutzutage nicht erwarten würden, dass sich eine Softwarelösung im Laufe der Zeit nicht weiterentwickelt. Wir übersehen Softwareprojekte, die im letzten Jahr nicht aktualisiert wurden, und stöhnen über Produkt- und Kundensupport, der keine klare Roadmap erstellt. Und selbst wenn dies gut gelingt - Sie erhalten eine klare Roadmap, guten Support, regelmäßige Updates ... - besteht jetzt immer die Chance, dass ein Herausforderer mit exponentiellem Wachstum auftaucht. Wir machen oft den Fehler zu denken, dass die großen etablierten Unternehmen immer dominieren werden, genau weil sie dominieren. Auf die gleiche Weise, wie das dominante Element in einer Herde älter wird, wird auch die übergroße Software / Hardware / welcher Anbieter auch immer älter. Oder nur ein bisschen faul. Und ein Herausforderer kommt herein und dreht die Dinge noch schneller um, als es der etablierte Dominant vor 5 oder 10 Jahren getan hätte. Oder die Dominante schlägt sich nur gut und überlebt kaum, während wir eine Marktstörung sehen (wirtschaftlich gesehen, mit Auswirkungen auf verschiedene Bereiche), und dann geht es weiter. Das sieht vielleicht unvollkommen aus, ist aber an sich ein organischer Prozess.

Aus der Sicht des Benutzers denke ich, dass das Problem nicht so groß ist. Code Rot tritt aus Sicht des Benutzers nicht auf, da er eine Alternative verwenden kann (möglicherweise mit nahtlosem Übergang / nahtloser Migration ... hoffentlich).

Nehmen wir nun an, wir sehen die Dinge nicht aus der Sicht des Benutzers oder sprechen von einem System, das - aus unbekannten Gründen, aus Gründen der Regierungsentwicklung, aus Gründen des Weltraumverkehrs usw. - immun gegen Wettbewerb ist und eigentlich von Wettbewerb ausgeht Um lange leben und überleben zu können, müssen wir uns die Texte ansehen, auf die Sie verwiesen haben. Und wahrscheinlich etwas mehr Literatur über zuverlässige Systeme und fehlertolerante Systeme. Obwohl wir wahrscheinlich weiter vorantreiben wollen. Wir wollen nicht nur Fehlertoleranz, wir wollen evolutionäre Systeme.

Das Problem mit der Evolution ist, dass sie Änderungen einführt und Änderungen Fehlerpunkte einführen. Schauen wir uns diese jetzt an und was wir tun können, um sie anzugehen.

Dabei können wir uns immer noch auf die Metapher Infrastruktur / Architektur / Emgineering verlassen (schließlich sind wir alle selbst Softwareingenieure, obwohl es im Moment wohl keine Softwareentwicklung gibt ...). Es gibt einen Grund, warum das Röhrensystem noch aktiv ist (mit einigen Störungen), Big Ben noch arbeitet (mit einigen Störungen) oder der Eiffelturm noch steht. Es liegt daran, dass wir mit wichtigen (oder weniger wichtigen) Elementen einer Infrastruktur genau das tun, was wir mit Software tun sollten: kontinuierliche Inspektion. Diese Einheiten waren nicht unbedingt auf eine so lange Lebensdauer ausgelegt, profitierten jedoch von ständiger Überwachung und zeitnahen Verbesserungen und Reparaturen, wenn dies erforderlich war. Nennen Sie das Ihre Hotfixes, wenn Sie werden.

Auf der anderen Seite sollten einige Designs dauerhaft und ohne Unterbrechung funktionieren, selbst wenn man weiß, dass eine kontinuierliche Inspektion nicht möglich ist. In diesem Fall wenden wir uns gutem Design und formalen Modellen zu. Elemente der Zuverlässigkeit (Verfügbarkeit, Zuverlässigkeit, Sicherheit, Integrität, Wartbarkeit) können für eine bestimmte Umgebung quantifiziert werden. Stats erledigt den Rest, um für den Rest und die Zukunft zu planen. Was die Frage aufwirft: Ist es uns überhaupt möglich, evolutionäre Systeme im eigentlichen Sinne zu bauen?

Jeff Langer in Clean Code stellt eine ähnliche Frage ... ohne Verweise auf Dampfleitungen:)

Was wäre, wenn Sie vier einfache Regeln befolgen könnten, die Ihnen dabei helfen würden, gute Designs während Ihrer Arbeit zu erstellen? Was wäre, wenn Sie durch Befolgen dieser Regeln Einblicke in die Struktur und das Design Ihres Codes gewinnen und so die Anwendung von Prinzipien wie SRP und DIP erleichtern würden? Was wäre, wenn diese vier Regeln die Entstehung guter Designs erleichtern würden?

Viele von uns sind der Meinung, dass die vier Regeln von Kent Beck für einfaches Design eine wichtige Hilfe bei der Erstellung gut gestalteter Software sind.

Laut Kent (in Extreme Programming Explained) ist ein Entwurf „einfach“, wenn er folgenden Regeln folgt:

• Führt alle Tests aus
• Enthält keine Vervielfältigung
• Drückt die Absicht des Programmierers aus
• Minimiert die Anzahl der Klassen und Methoden

Um alle Tests durchführen zu können, müssen Tests durchgeführt werden. Dies ist ein riesiger Indikator für die technische Verschuldung. Wenn ein System wie Mercury Quality Center beispielsweise 10.000 Testfälle enthält und keiner dieser Tests automatisiert ist, ist dies ein eindeutiger Indikator für die angehäufte technische Verschuldung.

Und hier kommen Feathers und sein Buch "Working Effectively with Legacy Code" ins Spiel.