Zum Inhalt springen

IT-Komplexitätsverkäufer & Convenience-Produkte

Beginnen wir mal mit einem sehr einfachen Bild:

Niemand braucht hunderte Arten von z.B. Supermarkt-Schokolade und Convenience-Lebensmitteln, trotzdem sind die Läden voll damit, verdrängen oft „ehrliche“ Produkte ohne Zusätze. Ähnliches bei anderen Suchtmitteln, wie Alkohol oder (noch immer) Tabak. Diese Produkte sind überwiegend für Konsumenten schädlich, trotzdem werden sie prominent und in großen Variation produziert, beworben, verkauft und konsumiert.

Eine verkürzte Begründung würde lauten: „Der Markt/die Kunden verlangen dies!“.

Aber warum brauche ich es?


Ähnlich ist es in der IT: Seit ich mich damit beschäftige, werden laufend neue Frameworks und Abstraktionsebenen veröffentlicht, die – zumindest früher – komplexe und schwierige „low level“-Programmierung durch einfacher zu nutzende Methoden und Schnittstellen ermöglicht haben. Dazu kam das entsprechende Tooling (IDEs, visuelle Interface-Builder etc) – man konnte viel schneller Produkte fertigstellen und veröffentlichen und damit Geld verdienen.

Heute ist es aber nicht nur komplexer in der Entwicklung sondern auch ohne messbare Vorteile für viele Nutzer. Man muss man für verschiedene Plattformen und Bereiche inkompatible Technologien einsetzen oder sich mit „eher schlechten“ plattformübergreifenden Frameworks begnügen. Kunden sind auch in Silos gefangen (Android vs iOS vs Web vs Desktop-Native).

Der Ausdruck „Balkanisierung“, wenn auch politisch inkorrekt, trifft die Situation recht gut: Eine Explosion, die aus wenigen universellen Technologien, Sprachen, Frameworks, Bibliotheken einer unbeherrschbare Vielfalt gemacht hat, die niemand überblicken kann und für die niemand sagen kann, ob sie in 2-3 Jahren noch existieren und ein „sicheres“ Investment sind.

Immer erst später erkennt man, wie nah früher der Markt/das Ökosystem am produktiven Optimum waren und wie viel Schrott und qualitativ schlechte Zusatzstoffe mittlerweile hinzugekommen und nicht mehr wegzudenken sind – ausser durch bewussten Verzicht!

Kommt ein neues Projekt mit dem Anspruch „eine gemeinsame Grundlage“ zu legen, dann passiert jedenfalls genau das nicht. Der Markt wird gespalten und ein neues Silo voller Eigenheiten und Komplexitäten aufgebaut. Einerseits braucht es dann „weitere Spezialisten“, aber die Produktivität pro Entwickler sinkt dramatisch, denn der Markt ist endlich d.h. Entwicklungs- und Betriebskosten steigen im Verhältnis zum Umsatz und es entsteht eine immer größer werdenen Markteintrittsbarriere für neue Produkte.

Kakao-Innovation:

Schokolade, Schokolade mit Nuss.

Schokolade mit Daim.

Schokolade mit OREO-Keksen.

Schokoladeneis!

Schokoladeneis mit Daim.

Schokoladeneis mit OREO.

Eis-Torte mit OREO, Daim, Schokolade, Kuchenteig, Salz und den besten Arteriengiften aus Palmöl und Milchpulver!

Auch hier kann die passende Fabrik sicherlich unbeschränkt viele Produktvarianten produzieren, aber die Regalplätze in den Supermarktfiliale ist beschränkt, müssen oftmals sogar gekauft werden und dauerhaft einen Mindestumsatz bringen. Was nicht performt, wird ausgelistet.

Man steht also im Supermarkt vor den Regalen und sieht nur noch populäre Fertigprodukte – auch frisches Gemüse ist nicht frisch sondern Tage alt und nährstoffarm, dafür „schön beleuchtet“ um den Frische-Eindruck zu erwecken. Nur noch wenige Kunden können und wollen selbst kochen – ohne Maggi und Knorr.

95% der Produkte sind versetzt mit ungesunden teilweise auch süchtig machenden aber zumindest prägenden Zusatzstoffen: viel Zucker, schlechte Fette, Einheits-Aromen („Erdbeer-Geschmack“, definiertem „Orangensaftkonzentrat“). Dazu ein durch Werbung und Kultur etabliertes Branding (Wer kannte Oreo vor 10 Jahren in Deutschland?).

Während ein Schokoladenhersteller mit etwas Logistik und Automation problemlos 1000 verschiedene Sorten herstellen und am Markt „ausprobieren“ kann, so kann das ein Entwickler oder Administrator nicht. Jeder Hype stellt für ihn ein Risiko dar: Lohnt sich die zeitaufwändige oft unbezahlte Einarbeitung, weil der Markt den Skill nachfragen wird? Oder verschwendet man seine Zeit mit einem Nischen-Silo? Wann sollte man „abspringen“ von etablierten aber „uncool“ gewordenen Dingen? Wie schlau ist es, sein Unternehmen oder seine Karriere auf 758 fremde nodejs packages aufzubauen?

Manche konzentrieren sich – spät und nach mühsamer Entwöhnung/Entzug – bei Lidl auf Tiefkühl-Rosenkohl, Tiefkühl-Blumenkohl, Tiefkühl-Brokkoli und Tiefkühl-Gemüsemix („OHNE ZUSATZSTOFFE“, Fette, Butter, Gewürze) – für läppische 1,60€ das Kilo. Direkt ab Ernte schockgefrostet, zuhause dampfgegart oder ehrlich mit etwas Käse und Salz überbacken.

In der IT können manche noch oder wieder Probleme mit einfachen Mitteln lösen, mit Bash, Ruby, Python oder schlicht bedachter Arbeitsweise, die auf den Punkt ein Problem lösen und damit Geld verdient („YAGNI„). Durch Reverse-Engineering von bestehendem Code, Hinterfragen von Anforderungen und Auswertung von Nutzerfeedback.

Wenig erstaunlich gibt es selten Jobs mit diesem Anforderungsprofil oder es handelt sich um ausbrennende „Feuerlösch-Jobs“ ohne leistungsabhängige Vergütung: Menschen und Unternehmen verbrennen problemlos monatelang Ressourcen um dann mit sehr wenig Restbudget nach notwendigen „Rettungskräften“ zu suchen, die Bestandssysteme oder Migrationen noch „retten“ sollen.

Der Fokus auf die eigentlichen Herausforderungen ist vollständig verloren gegangen.

Letztlich sind wir Menschen – alle! – wunderbar in der Lage, uns selbst lange etwas vorzumachen. Jeder sich selbst gegenüber und gegenüber seinen Mitmenschen, Kollegen, Kunden. Wir ignorieren langfristige Nachteile, sehen bunte Produktverpackungen, fallen auf durch Konsum suggerierte Emotionen hinein („Glück“, „Erfolg“, „Anerkennung“, „Lust“, „Respekt“, „selber Stack wie Google!“) und sind nur selten bereit oder überhaupt fähig, uns davon wieder zu lösen.

Wir unterschätzen Risiken, wenn andere den gleichen Unfug machen, überschätzen Risiken, wenn wir selbst etwas selbst umsetzen. Wir wollen keine Verantwortung übernehmen. Wir schätzen funktionierende Bestandslösungen zu schlecht ein und überschätzen Werbeversprechen von Anbietern, die erstaunlicherweise mit der „Lösung“ überhaupt kein Geld verdienen wollen (was schlicht gelogen und eine Falle ist).

Wir sind extrem schlecht darin zu beurteilen, was ein „Fortschritt für uns“ sein kann und was ein Rückschritt sein wird (der dafür anderen Playern dauerhaft Mehreinnahmen durch ein neues Abhängigkeitsverhältnis beschert). Wir fallen immer wieder auf „einfache Lösungen“ herein – auch politisch.

In der Wissenschaft zählen Fakten: Definierte Aufbauten, Durchführungen und ihre gemessenen Auswirkungen gegenüber einer Kontrollgruppe – daraus werden dann Schlüsse gezogen. In der IT-Branche sieht man allenfalls A/B-Tests zur Konversationsoptimierung im Bereich SEM/E-Commerce, selbst wenn mittlerweile alle möglichen Metriken zentral erfasst werden und mit zB Grafana oder Datadog auch schön bunt aber oftmals nutzlos visualisiert werden. Konkurrierende Experimente werden selten definiert. Und was ist das Ziel? Und was ist nochmal die Ausgangslage? Wie misst man Komplexität? In welchem Verhältnis steht Komplexität zu Laufzeitkosten?

In der IT transplantieren wir deshalb laufend Bestandssysteme ohne konkrete Analyse der bestehenden Beschwerden oder der Lebensweise, die möglicherweise die Ursache der Probleme sind. Ob Wechsel zu Microservices, Migration „in die Cloud“/proprietäre AWS-Services, Containerization, Kubernetes – alles schön und toll, aber nicht wenn man die Ursache des möglicherweise suboptimalen Bestands-Zustandes nicht korrekt analysiert hat und die Probleme dann mit hoher Wahrscheinlichkeit wieder erleiden wird. Niemand will es, aber es passiert laufend.

Viele Menschen saufen, fressen und rauchen — nicht, weil sie Durst oder Hunger leiden, oder „etwas anzünden“ wollen, auch nicht weil sie die Gefahren und Folgen nicht kennen, sondern weil sie damit andere Bedürfnisse zu stillen versuchen und/oder abhängig geworden sind. Natürlich gelingt das nicht und sie ruinieren sich und manchmal auch Unternehmen.

Ein ähnliches Verhalten sehe ich seit Jahren in der IT.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

* Die DSGVO-Checkbox ist ein Pflichtfeld

*

Ich stimme zu