Technische Schulden entstehen, wenn Software nicht auf dem aktuellen Stand gehalten wird. Schulden können bereits anfangs eingebaut werden (indem zum Beispiel kein Konzept für Benutzerrechte implementiert wird) oder sie fallen im Lauf der Zeit an, wenn Anpassungen an neue Anforderungen, eine neue Version des Betriebssystems oder Sicherheitsupdates unterbleiben.
Mehr dazu in der Wikipedia.

Es soll hier nicht um mich gehen, trotzdem eine Anekdote aus meiner Vergangenheit. Als ich in der zweiten Hälfte der 1990er Jahre anfing, ein Windows-Programm zu schreiben, sah es bei Programmierumgebungen so aus:

Firma Borland mit Delphi war weit verbreitet. Borland wurde später von MicroFocus geschluckt, Delphi landete dann bei Embarcadero und ist auch heute noch erhältlich.

Da ich C++ verwenden wollte, kam Delphi allerdings für mich nicht in Frage, damals gab es von Borland noch kein Windows-Pendant zu meinem geliebten Turbo-C unter MSDOS. Es blieben zwei Möglichkeiten: Das Watcom-Toolkit und Microsoft Foundation Classes. Ich entschied mich für Microsoft. Das war nicht durch und durch erfreulich; nach wenigen Jahren stellte sich heraus, dass auch mit dem Large Memory Model kein Programm mit mehr als 64 KB Code und mehr als 64 KB Daten entwickelt werden konnte. Daraufhin war der Wechsel auf echte 32 Bit angesagt, was einer weitgehenden Neuprogrammierung gleich kam. Im Laufe der weiteren Jahre hatte Microsoft die Foundation Classes mehrmals vernachlässigt und versucht, Developer zum Umsteigen auf C# zu bewegen -- so gab es einige Jahre kein Intellisense für C++. Letztlich führte die große Developer-Basis
aber dazu, dass Microsoft C++ und die Foundation Classes weiter pflegte, so war die Kompatibilität zur jeweils aktuellen Windows-Version gewährleistet und man konnte auch moderne Benutzerelemente (Ribbon...) verwenden.

Firma Watcom, der C-Compiler und das Toolkit entwickelten sich nicht langfristig weiter. Watcom wurde 1995 von Sybase geschluckt, der C-Compiler und das Toolkit wurden dann 2003 als Open Source veröffentlicht -- vielleicht sollte man auch »entsorgt« sagen. Ein Überblick in der Wikipedia.
 

Es geht hier um einen bedeutenden Anbieter von Warenwirtschaftssoftware für Apotheken. Dieser Anbieter gehört zu den vier (?) Firmen, die nach den Konzentrationsprozessen der letzten Jahrzehnte übrig geblieben sind.

Er stand wohl zur selben Zeit wie ich vor der selben Entscheidung und wählte damals das Watcom-Toolkit. Es wäre dann wohl spätestens zur Jahrtausendwende angesagt gewesen, in den sauren Apfel zu beißen und die Software auf einer anderen Basis neu zu schreiben. Das fand nicht statt. Ich war einige Jahre gezwungen, diese Software zu benutzen. Zuerst zu den Nachteilen des Watcom-Toolkit, die ich als Benutzer empfand:

• Die Benutzeroberfläche kennt nur wenige Elemente: Texteingabefelder, Schaltflächen, Menüs, Tabs. Das bedingt, dass manche Dinge nur umständlich erledigt werden können. Wenn Sie schon einmal einen Verkaufsvorgang mit mehr als 10 Positionen nachbearbeiten mussten, wissen Sie, wovon ich spreche.
• So etwas wie Tooltips gibt es nicht.
• Die Benutzeroberfläche ist inkonsistent. Dialoge werden (wenn man keine Maus benutzen möchte) mal mit der Enter-Taste, mal mit der Leertaste, mal durch dreimaligen Druck auf Tab und dann der Leertaste, mal mit einem (wechselnden) Hotkey und mal mit Escape geschlossen.
• Für Dinge wie die Taxation von Auseinzelungen wäre ein Assistent oder eine vergleichbare Art der Benutzerführung hilfreich.
• Vermutlich können mit dem Watcom-Toolkit keine DLLs programmiert werden. Das bedingt, dass für die Sternchensuche ein gesondertes Programm benötigt wird. Dies macht das System langsamer, dazu kommt, dass es im Alltagsbetrieb
  immer mal versehentlich geschlossen wird.
• Die Software besteht auch sonst aus unzählig vielen Programmen. Wegen der Beschränkung auf 64 KB Codegröße führt dann selbst die Eingabe eines Artikelnamens in der Kasse dazu, dass ein gesondertes Programm mit der Artikelübersicht gestartet wird. Auch hier gilt: Alles wird langsamer. Manchmal verliert man sich zwischen den vielen Fenstern.
• Vieles ist angeflanscht anstatt eingebunden.
  • Im Menü der Artikelauskunft findet man nach einigem Suchen den »neuen Apothekenstamm« und damit den Zugriff auf den Langnamen eines Artikels. Eine Listenansicht der Langnamen fehlt. Ach ja, der »neue« Artikelstamm ist seit 2004 offiziell verbindlich im Einsatz. Für Arzbneimittel mag er entbehrlich sein; für Medizinprodukte und Kosmetik ist er essentiell.
  • Ähnlich prickelnd ist es mit E-Rezepten. Auch hier wird außerhalb der Kasse ein separates Programm gestartet.
  • Es gibt eine anklickbare Liste von Benutzern. Leider sieht man in der Kasse nicht ohne weiteres, dass man sich anmelden muss - so etwas wie ein Sperrbildschirm fehlt. Bemerkbar macht sich das erst, wenn man seine Eingabe abschickt und diese dann gelöscht wird.
• Für einige Aufgaben (zum Beispiel den Umgang mit Webservices) eignet sich C++ prinzipiell nicht. Für beispielsweise E-Rezepte und Z-Daten ist Kommunikation mit Programmen aus einer anderen Welt erforderlich. Das trägt erheblich zur Unübersichtlichkeit bei.
  • So kam es öfters vor, dass ein Vorgang in der Kasse erfolgreich bearbeitet wurde und Stunden später fiel dann auf, dass er in der elektronischen Rezeptübertragung gescheitert war.
  • E-Rezepte müssen nach Bearbeitung manuell zum Abrechner geschickt werden. Bei Änderungsbedarf darf man sie dann manuell vom Abrechner zurückholen, bevor man sie bearbeiten kann (wenn man sie denn bearbeiten kann, das klappt nämlich nicht bei jedem abgeschlossenen Vorgang).
• Als Benutzer erlebte man einen deutlichen Bruch zwischen den Watcom-Programmen und Java-Software (Berichte) oder Web-basierten Oberflächen (Chipkarten-Management), die gelegentlich auch benutzt werden mussten.

Betrachten wir jetzt vielleicht noch die Situation der Firma:

• Entwickler, die mit dem Watcom-Toolkit vertraut sind, sind kaum zu bekommen. Jeder neue Entwickler muss sich also tief einarbeiten.
• Änderungen an vorhandenen Programmen erfordern spezielle Klimmzüge, wenn die maximale Programmgröße erreicht wird.
• Eine einheitliche Bedienung ist schwierig zu erreichen, wenn Bedienelemente nicht einmal, sondern dutzende Mal implementiert werden müssen.
• Jetzt noch auf eine andere Programmierumgebung umzustellen, erfordert Ressourcen in einem Maß, das nicht zu stemmen ist.

Der Wechsel eines Warenwirtschaftssystemes ist teuer, aufwändig und ein Sprung ins Ungewisse. Der Anbieter kann seine verbliebenen Kunden also vermutlich großteils noch einige Zeit halten, neue wird er nicht gewinnen. 

Ironie der Geschichte: Die beschriebene Firma hatte ein modernes, durchdesigntes Java-basiertes System zugekauft, das leider in der Frühzeit als Bananensoftware auf den Markt gebracht worden war und deswegen einen schlechten Ruf hatte. Diese Java-Software ist inzwischen eingestellt.