Programmierstandards - Feedback und Ideen

[Fuerchau]

Auch hier denke ich, dass Java mit ein Grund ist.
Nur mit C/C++ lässt sich maschinennaher Code entwickeln.
Die Java-VM selber ist sicherlich der Kandidat für C/C++ um diese für diverse Plattformen verfügbar zu machen.
Der Rest erfolgt wiederum in Java.

Man bedenke, das Android ein Java-Derivat ist!
Und wo läuft das alles so?

Mein Blu-Ray-Player hat ebenso Java und demnächst wohl auch der Kühlschrank.

[ExAzubi]

Also ich muss sagen, das Kollege Bender schon sehr Recht hat. Ich kann ein Auto, das ich 1985 entworfen und gebaut habe, nicht immer wieder mit neuen Errungenschaften erweitern.
Denn entweder passt das alles nicht mehr, oder aber es ist so verbaut, das keiner mehr einen durchblick hat.

Ich bin der Meinung, das gerade ein Softwarehaus, ihre Software nach 10-20 Jahren neu aufsetzen muss, um Konkurenzfähig zu bleiben!
Natürlich braucht man dafür Performance und Manpower, aber ich denke es würde heute auch keinen Autobauer mehr geben, der seine aktuellen Modelle auf einer Plattform von vor 30 Jahren baut!

Als Kunde mache ich natürlich das was im Unternhemen eingesetzt wird. Ich würde kein 30 Jahre altes ERP -System (GEAC, STEEB, ...) was aktuell im Einsatz ist, auf modernste Techniken umschreiben.
Wenn es läuft und nur ggf. Erweitert werden muss dann mache ich bein den Original-Sourcen nicht vorher ein CVTRPGSRC, das wäre Sinnfrei und würde ggf. die Useability "zerstören" da Masken & Verhalten sich ggf. von 98% der anderen Programmen ändern würden.

[dschroeder]

Ich denke, dein Vergleich mit dem Auto passt zu Standardsoftware. Die kann vergleichsweise leicht durch eine neue Version ausgetauscht werden.
Die Kernanwendungen in unserem Unternehmen sind alle individuell programmiert (egal, ob RPG oder Java). Da kann kein Externer für uns einfach eine neue Version programmieren und dann alles austauschen. Das würde ich anstatt mit einem Auto eher mit einem Haus vergleichen, an dem man lange gebaut hat. Wenn da eine Erweiterung notwendig ist, reißt man es ja nicht sofort komplett ab und baut neu. Da macht man einen Anbau, der dann natürlich nach dem neuesten Standard errichtet wird. Meine Idee ist, dass man irgendwann viele Erweiterungen nach neuerem Standdard hat, so dass man das Ursprungsgebäude räumen kann. Das wird dann durch einen neuen Anbau an (die Erweiterungen) ersetzt. Also Evolution anstatt Revolution.

Dieter

[andreaspr@aon.at]

Also ich muss sagen, das Kollege Bender schon sehr Recht hat. Ich kann ein Auto, das ich 1985 entworfen und gebaut habe, nicht immer wieder mit neuen Errungenschaften erweitern.

Um bei der Metaffa zu bleiben:
Nur weil mein Auto 1985 gebaut wurde, heißt es nicht, dass ich kein modernes Navi verwenden kann welches ich vielleicht sogar auch fürs Motorad oder andere Autos benutzen kann.
Oder eine "moderne" Dachbox ...
Ich würde nicht alles so schwarz/weis sehen.
Aber stimmt schon nicht immer funktionierts so einfach.

[B.Hauser]

Ich bin der Meinung, das gerade ein Softwarehaus, ihre Software nach 10-20 Jahren neu aufsetzen muss, um Konkurenzfähig zu bleiben!

Versuch mal ein Buchhaltungssystem neu zu schreiben!

Leider hat sich der Vorteil, den IBM immer angepriesen hat, d.h. Abwärtskompatibilität ohne irgendwelche Anpassungen zum Nachteil entwickelt.
Viele Unternehmen (Softwarehäuser oder nicht) haben das zum Anlass genommen, und nie in Aus- und Weiterbildung investiert.
Warum auch? Man kann ja immer noch im gleichen alten Stil wie 1988 oder sogar noch früher codieren.
Investition in Aus- und Weiterbildung wäre Verschwendung gewesen.
Damit hat man in den letzen 20 Jahren sich u.U. keinen Schritt vorwärts bewegt.
Und jetzt nach 20 Jahren wacht man auf! Das Geschrei ist groß, weil 20 verpennte Jahre kann man nicht in 2 Wochen aufholen!

In der PC-Welt hat es anders ausgesehen. Da war es klar, dass man die Leute auf dem Laufenden halten muss, weil ansonsten in 5 Jahren nichts mehr läuft. Da war Geld für Aus- und Weiterbildung, neue Systeme etc. immer genügen da.
Die IBM i (oder früher AS/400) Welt hatte das Nachsehen.

Wobei der Investitionsschutz ist als solches nicht schlecht. In einem WWS-System oder Buchhaltungssystem gibt es sicher ein paar Tausend Programme und wenn man einigermaßen am Ball geblieben ist noch wesentlich mehr Prozeduren, ggf. in unterschiedlichen Programmiersprachen, nach unterschiedlichen Konzepten (prozedural, OO) etc.

Ein solches Pakte schreibt man nicht mal "schnell" um!
Komplettes Umscheiben ist auch nicht notwendig, wenn man für Änderungen und Erweiterungen jeweils die neue und neueste Techniken eingesetzt hat.

Des weiteren kommt es gerade in Softwarehäusern auch immer darauf an, wer die Neuerungen auch bezahlt.
Bei jeder neuen Technik, ist immer ein gewisser Aufwand an "Ausprobieren" dabei und manchmal muss man alles nochmal in die Tonne treten. Dazu kommt noch der sonstige Aufwand für Konzeptionierung, Programmierung und Tests, die bei neuen Technologien immens sind.

A pro pos neue Technologien und Softwarehäuser. Wenn man nicht gerade SAP heißt, muss sich ein Softwarehouse immer nach dem letzten Kunden, der upgradet richten. Alle Änderungen müssen und mussten auf dem Release, das der "letzte" Kunde einsetzt lauffähig sein.
Früher waren die Release Zyklen 1,5 - 2 Jahre, IBM hat 3 Release unterstützt, d.h. wenn man sich an die IBM Regel hält war ein Softwarehouse 4-6 Jahre zurück. Jetzt wurde das Ganze umgestellt, d.h. jedes halbe Jahr gibt es einen Technology Refresh und die Release werden länger unterstützt. Release 7.1 hat jetzt den 11. TR (ist also schon fast 6 Jahre alt!). Das aktuelle Release ist 7.2 (auch schon wieder fast 2 Jahre alt).
Wir hatten Anfang Juli in diesm Jahr (als Release 7.1 auch schon 5 Jahre alt war!) beschlossen nur noch 7.1 oder höher zu unterstützen. Die Proteste unserer Kunden waren immens.

... und jetzt frag' mal wieviele Firmen noch Release V5R4 oder noch älter im Einsatz haben.

Erweiterungen nur um neue Technologien zu verwenden, will kein Kunde bezahlen.
Frag nicht wie oft ich schon bei meinem Chef antanzen musste weil ich etwas Neues ausprobiert habe und damit mehr Zeit als der Kunde gewillt war zu bezahlen benötigt hatte und mir dann anhören musste: "Hätten Sie ein altes Programm kopiert wäre das schneller gewesen".

Kurzfristig und blauäugig gedacht, nur leider ist sich zunächst mal jeder selbst der nächste (haben will ich's ja gerne, nur bezahlen dafür nicht!)!
... und leider sieht es in der Realität oftmals genau so aus.

Birgitta