Wer früher (70er) gut in Mathe und Physik war, beschäftigte sich auch gerne mit Computern und Taschenrechnern. Der Zusammenhang war klar: Informationstechnik beschleunigt das Rechnen, bzw. nimmt es dem Menschen ganz ab. Der Mensch muss nur wissen oder herausfinden, was berechnet werden soll. Einige dieser Schüler wurden später Programmierer. Sie entwickelten Großrechnerprogramme, mit denen Telefonrechnungen und Rentenansprüche berechnet werden. Bis heute.
Die Programmiersprachen entwickelten sich weiter, weil Innovationen die IT-Architekturen weiter entwickelten. Wir bekamen Hochsprachen, in denen es weniger ums richtige Rechnen ging, als um eine kluge Begriffsbildung für Objekte und Methoden und um benutzerfreundliche Dialoge und Oberflächen. Man muss eher ein guter Philosoph oder Linguist sein, um auch gut mit objektorientierten Sprachen umgehen zu können.
Diese Leute versuchen heute, die Altsysteme der Großrechnerprogrammierer durch moderne Architekturen abzulösen. Und stoßen gegen Decken und Wände.
Über die Gründe kann man genug im Social Web nachlesen und hören:
- Die Altsysteme, insbesondere die Anforderungen die sie erfüllen, sind nur in den Köpfen der damaligen Programmierer "dokumentiert".
- Dokumentation, die "nur" dem Teilen von Wissen dient bzw. jemand anderen als den bisherigen Eigner zu einer Neuentwicklung zu befähigen, gilt bei den Althasen als nutzlos, oder als Risiko.
- Arbeitsteilung zwischen Auftraggeber (Fachbereich) und Auftragnehmer (IT) gab es in den 70ern nicht. Man hatte eine Abteilung, die sich vom Nachbarbüro erklären ließ, was das System können soll.
Die heutige Generation denkt komplett anders:
- Arbeitsteilung heißt für sie: jeder macht, was er oder sie am besten kann. So macht es Spaß.
- Für Arbeitsteilung muss man Wissen teilen. So kommt man als Team voran in Richtung eines gemeinsamen Zieles.
- Anwendungen müssen dem Anwender nützen, nicht den Programmierer auszeichnen.
- Kompliziertheit ist kein Hinweis auf Genie sonder auf kompliziertes Denken.
Das Problem ist: Die Altsystemprogrammierer sind die Chefs. Die Jungen werden sie in absehbarer Zeit beerben. Sie erben dann Objekt- und Sourcecode und müssen sehen wo sie bleiben. Das ist in etwa so, als würden einem die Eltern als Testament ein unleserliches Notizbuch hinterlassen.
Warum ich den Beitrag erst heute in meinem Feedreader sehe, weiß ich nicht - sei es drum.
AntwortenLöschenDie Situation in den 70ern (und bis in die 90er) bis heute zu prolongieren, halte ich für ein wenig gewagt. Nach meinen Erfahrungen hat sich viel getan:
Ja, die Altsysteme sind sehr oft in den Köpfen der damaligen Programmierer "dokumentiert" - aber das liegt in den meisten Fällen, die ich kenne, nicht unbedingt an der IT-Seite, sondern weil die Fachseiten einfach keine Notwendigkeit sehen bzw. sahen, sich damit zu beschäftigen, "die IT macht das schon". Das hat sich geändert, zumindest dort, wo die Fachseite der treibende Faktor ist und auch Verantwortung übernimmt.
Ja, das Problem der Dokumentation ist immens, bei Altverfahren aber genauso wie bei neu(er)en. Genauso problematisch ist die Übergabe von Know-how und Wissen, das wird meist auf irgendeinem Altar geopfert.
Wenn jeder macht, was er am besten kann, dann ist da ein erhebliches Maß an Beliebigkeit und letztlich möglicherweise Flucht vor Verantwortung dabei. "Spaß" halte ich in diesem Zusammenhang für ein schwieriges Wort.
Die Altprogrammierer sind die Chefs? Klar, das gibt es. Aber sind sie deshalb schlechte Chefs, sozusagen geistig in alten Gefilden? Das mag es geben, aber es dürfte nicht die Regel sein. Ich habe ältere Kollegen oft als überaus kompetent und fortschrittlich erlebt. Und richtig gut kann es werden, wenn sie mit jungen Kollegen "aufeinanderprallen", neues Wissen und ungebremste Ideen hier, gewachsenes Wissen und Erfahrung dort. Das halte ich für eine ausgesprochene "Erfolgsmischung".
Wobei ich betonen muß: Natürlich müssen die Köpfe "stimmen". Und nicht zuletzt lebt die IT auch von Personalveränderungen.