Tick-tack-tick-tack-tick- Der leise Countdown im Code.

2008 habe ich meine Bachelorarbeit über eine ziemlich aufstrebende, zukunftsträchtige Technologie geschrieben: Microsoft hatte 2006 die Windows Presentation Foundation (WPF) veröffentlicht, und ich war begeistert von den Möglichkeiten.

2026 tragen wir nun die letzten produktiven WPF-Anwendungen zu Grabe – eine Geschichte über die Geschwindigkeit der Software-Industrie, tickende Zeitbomben und Argumente, warum auch gute Technologien ausgetauscht werden müssen.

RIP, WPF.

Die WPF war im Bereich der Benutzeroberflächen revolutionär. Dem Gestaltungsspielraum waren kaum Grenzen gesetzt: flexibel kombinierbare Steuerelemente, vektorbasierte Grafiken, Farbverläufe im Hintergrund, applikationsweites Styling, Animationen, Data-Binding, … - ich komme heute noch ins Schwärmen.

Ich war fasziniert, habe Vorträge darüber gehalten und über eine verwandte Technologie (UWP) sogar ein Buch geschrieben (meine Mama hat’s angeblich gelesen, darüber hinaus war der Absatz überschaubar).

Die WPF ist auch heute noch eine gute Technologie. Sie hat vielleicht nur einen zentralen Nachteil: Sie ist nicht webbasiert. Zwischen 2008 und 2014 hat sich das Internet nahezu verdoppelt¹ und mit immer leistungsfähigeren Bandbreiten und Technologien wanderten schrittweise fast alle Anwendungen in den Browser.

Es gibt zahlreiche gute Gründe für Webtechnologien: ein flexibler, weltweiter Zugriff ohne Installation, zentrale Updates, optimierte Darstellungen am Smartphone, ein besserer zentraler Datenaustausch mit anderen Web-Anwendungen und APIs.

Nur: Was tun, wenn man eine WPF-Anwendung hat, die stabil läuft und ihren Zweck erfüllt? Was, wenn man keine Notwendigkeit sieht, die Anwendung ins Internet zu bringen oder gar am Smartphone zu bedienen? Warum wechseln?

Das Problem sitzt vor dem PC.

Weil es Menschen benötigt, die diese Technologie noch verstehen und weiterentwickeln können. Haben vor gut 10 Jahren noch alle unsere Entwicklerinnen und Entwickler täglich mit der WPF gearbeitet, so werden heute nur mehr wenige Zeilen pro Jahr abwechselnd von 4 Personen getippt.

Auch in Ausbildungsstätten muss permanent hinterfragt werden, welche neuen Trends man in den Lehrplan aufnehmen möchte – und welche Inhalte „geopfert“ werden. Die WPF wird – wenn überhaupt – gestreift, heutige Absolventinnen und Absolventen haben üblicherweise keine praktische Erfahrung damit.

Ich unterrichte selbst Software Engineering an der Fachhochschule Hagenberg, wir haben die Übungseinheiten zur WPF (auch mit meiner Unterstützung) vor einigen Jahren halbiert und die Technologie aus dem Semesterprojekt entfernt.

Es ist also nicht immer das Problem, dass die Technologie unbrauchbar wird – sondern dass niemand mehr die Fähigkeit (und auch die Lust) hat, damit zu arbeiten. Als Unternehmen muss man danach trachten, sich auf bestimmte Werkzeuge zu fokussieren: so wie Autowerkstätten für gewisse Tätigkeiten nicht sämtliche Marken annehmen – und schon gar keine Oldtimer.

Bei Standardprodukten wird dieses Problem oft ausgesessen: Man wechselt einfach nicht. Man schafft sich seine eigene Blase mit Entwicklerinnen und Entwicklern, bildet selbst in der alten Technologie aus und wird gemeinsam alt. Irgendwie idyllisch, aber Innovationskraft sieht anders aus.

Wie lang tickt die Bombe?

Bei Software läuft kein Timer ab, es raucht nichts, es explodiert nichts. Man hat zwar irgendwann das Gefühl, dass die Software nicht mehr ewig halten wird, aber oft bleiben Lösungen in diesem komatösen Zustand noch ziemlich lange im Produktiveinsatz.

Am deutlichsten ist das Ende, wenn Inkompatibilitäten mit neuen Betriebssystemen oder neuer Hardware auftreten – im schlimmsten Fall überraschend beim nächtlichen Windows-Update oder am neuen Laptop des Geschäftsführers.

Alle anderen Themen werden viel zu oft auf die lange Bank geschoben, weil sie im Alltag keine unmittelbar sichtbare Auswirkung haben: Sicherheitsrisiken durch fehlende Updates, ein immer komplexerer und schwer zu verstehender Sourcecode („technische Schulden“), dadurch einhergehende Angst vor Änderungen und eine verabsäumte Anpassung an neue Anforderungen oder rechtliche Rahmenbedingungen.

Überzeugungsarbeit

Es liegt aber auch an uns, die Vorteile eines Technologieupdates zu suchen und zu argumentieren. Wir dürfen uns nicht wundern, dass das Angebot „es kostet dich viel Geld und du hast danach dieselbe Funktionalität (mit ein paar neuen Fehlern)“ zu keinem spontanen Applaus führt. Eine neue Framework-Version ist für den End User noch kein Mehrwert.

Einige Ideen, die aus unserer Erfahrung beim Umstieg von Desktopanwendungen zu Webtechnologien geholfen haben:

ein modernes, neu gedachtes User Interface-Design als Appetizer,
Vorschläge für erweiterte Nutzerkreise liefern (z. B. Self-Service-Funktionalität, die bisher nicht möglich war),
Motivation und die Lust am Neudenken mancher Prozesse entfachen,
Arbeiten von zu Hause aus ermöglichen,
Performance-Optimierungen anbieten und
bessere Supportqualität und schnellere Updates garantieren.

Wir müssen uns eingestehen, dass wir nicht alle Technologien seriös über Jahrzehnte betreuen können. Wichtig ist aber eine frühzeitige und ehrliche Kommunikation, die einem Kunden auch die Gelegenheit gibt, das entsprechende Budget und die internen Ressourcen bereitzustellen: 2-3 Jahre Vorlaufzeit sind unserer Erfahrung nach keine Seltenheit.

Unterschiedliche Geschwindigkeiten

Bemerkenswert ist, dass nicht alle Technologien gleich schnell altern – und es wirkt fast, als würden die klassischen drei Schichten der Software-Architektur auf getrennten Umlaufbahnen kreisen: Datenbanken, Backend-Code und Frontend laufen unterschiedlich schnell.

Die Art und Weise, wie man relationale Datenbanken baut, hat sich in den letzten Jahrzehnten nicht grundlegend verändert. Natürlich gibt es auch dort Innovation, aber eine bestehende Datenbank aus 2008 für eine neue Webanwendung im Jahr 2026 zu übernehmen, ist durchaus eine plausible Überlegung.

Backend-Code, in unserem Fall mit .NET und der Programmiersprache C# geschrieben, ist sicher dynamischer. Hier ändern sich regelmäßig Bibliotheken, es kommen neue Sprachfeatures und Tools hinzu – aber die Entwicklung ist evolutionär.

Kein Vergleich zu Frontend-Technologien: Hier dreht sich in den letzten 10 Jahren das Rad deutlich schneller und neben neuen Frameworks und erweiterten Browserfähigkeiten spielt natürlich auch die Kurzlebigkeit von grafischen Designs und Trends eine Rolle.

Mit diesem Wissen bekommen zwei Bereiche eine höhere Aufmerksamkeit: AI und Architektur.

AI und Architektur

Architektur deshalb, weil sich jetzt bezahlt macht, ob das Haus stabil gebaut wurde. Im Idealfall kann die Fassade neu gestrichen und der Garten bepflanzt werden, ohne dabei einen Kellereinsturz zu riskieren. Vor allem beim Wechsel zwischen verschiedenen Web-Frontendtechnologien ist eine durchdachte, funktionsfähige API-Schicht (inkl. Backend-Code und Datenhaltung) Gold wert.

AI deshalb, weil in Kombination mit einer guten Architektur die Transformation von bestehendem Code in neuen Code durchaus eine Stärke aktueller AI-Coding-Tools ist. Wir haben bereits gute Erfahrungen bei AI-unterstützten Technologieupdates gesammelt und können so teilweise die Aufwände deutlich senken.

Resümee

Ich werde alt. Wir begraben heuer eine Technologie, deren Aufstieg ich in meinem Berufsleben aktiv miterlebt habe. Aber vor allem das im Team schrittweise fehlende Know-How und die mangelnde Praxiserfahrung muss dazu führen, frühzeitig betroffene Projekte und Kunden zu informieren und mit guten Argumenten einen Technologiewechsel herbeizuführen.
Sonst werden wir auch als Unternehmen alt, und das wollen weder wir, noch unsere Kunden.

gemessen an der Anzahl der Rechner im Internet (Quelle: Wikipedia) ↩︎