Noch immer hat die einen Ingenieur umgebende Technologie großen Einfluss auf seine Arbeit, also auch auf das, was der Anwender als Ergebnis erhält:
Die Pyramiden sähen anders aus, wenn es damals schon Beton gegeben hätte.
Wer mit der Draisine fährt, käme nicht auf die Idee, einen Speisewagen zu suchen.
Der Benutzer eines Dialogsystems, das auf einer Siemens PBS des Jahres 1970 entwickelt wurde, ist froh, wenn er eine "1" für das Geschlecht angezeigt bekommt; den Text "männlich" würde er bestimmt nicht erwarten.
Ein Space Shuttle wäre eine Kugel von 50 Meter Durchmesser, wenn die Umpolung der Schwerkraft schon erfunden wäre.
Genauso hat ein Hauptspeicher von 12 KB, den der Autor in seinem ersten Mainframe, einer IBM 360/20, vorfand, oder auch die Notwendigkeit, den Online-Dialog über CICS abzuwickeln, dramatische Auswirkungen auf das Softwaredesign und die Anwendung selbst. Im Software-Engineering gilt also "Technology Drives Design". Aber dessen ist sich der Softwareingenieur selten bewusst, wenn er eine Anwendung entwickelt.
Die vergangenen acht Jahre waren beherrscht vom Framework-Hype. Die Idee stammt eigentlich aus der Steinzeit: Lege alles in eine Ecke deiner Höhle, was du bei deiner Arbeit vielleicht einmal brauchen könntest, also Sehnen, Knochen, einen spitzen Stein etc. Wenn dann das Steinbeil bricht oder der Feuerbohrer nicht mehr funktioniert, findest dort vielleicht etwas, das dir hilft.
So alt die Idee auch ist - eigentlich ist sie immer noch ausgezeichnet. Aber wenn man beobachtet, wie Framework auf Framework gepackt und das Ganze mit wieder anderen Frameworks kombiniert wird, kann einem schon angst und bange werden. Die Softwareingenieure müssen aufpassen, dass sie nicht in die Falle ihrer Väter tappen. (Siehe dazu auch: "Ist Java das neue Cobol?") Denn der Feind des Guten ist das Bessere: Auch Frameworks veralten. In zehn Jahren werden die Frameworks von heute Geschichte sein. Und wie bitte soll dann der wirtschaftlich relevante Teil der Anwendungssysteme gerettet werden?
