Coding - schnelle Lauffähigkeit auf dünnem Eis oder die robust-gute Wartbarkeit samt Allperspektivität von DevOps?

No Code, Low Code, Vibe Coding, Miracle Coding, Magic Bullets und rasch gepromptete Agentensysteme: Manchmal wird es zum zentralen Problem, dass wir es uns von Anfang an zu einfach machen wollten. Später müssen dann hoffentlich andere Leute aufräumen: ein PAL (Problem Anderer Leute) ist entstanden. Gleiches gilt für unterkomplex verstandene Agilität. Repositories wie Github quellen über vor neuem Code, den jetzt jeder ohne besondere Kenntnisse rasch herbeiprompten kann. Auch nur eine der vielen Arten an AI‑Slop, von dem das Internet überschwemmt wird.

Es sollte anders laufen, wenn die Software zu Kunden geht, beispielsweise „embedded“ auf Hardware-Steuergeräte aufgespielt wird oder in Fertigungsprozessen der Produktion ihren Dienst tun soll. Egal, ob klassisches Coding oder Agentensysteme: es braucht sauber formulierte, möglichst in UML visualisierte und vollständige Spezifikationen sowie cyberbersicher umsetzbare Architekturen: Die Liste unsicherer Befehle einer Programmiersprache ist dabei, wie vieles andere auch, ziemlich hilfreich. Damit nicht genug: Das große Stichwort heißt „Egoless Coding“: Software‑Entwicklern bereitet es häufig Freude, „coole“ Strukturen zu programmieren. Rekursionen wie im Bild sind ein Beispiel, nur eines von vielen hausgemachten Cyberrisiken und Entropieerzeugern. Diese und viele andere entstehen still ganz nebenbei als schnelle Workarounds: copy/paste von Codeabschnitten, bei denen ein eigenes Modul langfristig sinnvoll und sicher gewesen wäre. Ein gut gekapseltes, gemeinsames Modul hätte allerdings Abstimmung erfordert - bloß das nicht 🙄! Notwendige Änderungen finden dann nur an einigen der gedoppelten Bereiche statt, dort wo sie halt auffallen. Die Entropie (Kraut‑und‑Rüben‑Chaos) des Codes steigt, er „müffelt“. Die Einarbeitung neuer Mitglieder im Team wird laufend aufwändiger, alle sind überlastet und es bedeutet immer mehr kognitive Last, mit den angehäuften sog. „technischen Schulden“ umzugehen. Da hilft auch kein Style Guide, kein GitHub, GitLab, Git Flow oder‑wie‑es-auch‑sonst‑heißen mag: Es existiert auf dieser Welt weder ein gutes Kollaborationstool noch eine gute Managementphilosophie. Es existiert immer nur eine gute oder weniger gute Passung zwischen Geschäftsziel, Persönlichkeiten, gelebter Kultur und Toolset bzw. Managementansatz.

Hier kommt „Conway's Law“ ins Spiel: danach ist die Architektur von Software bzw. der IT ein Spiegel der Struktur der Firma. Das ist meist nicht als Kompliment zu verstehen. In Ab‑Teilungsstrukturen (bewusst so geschrieben) werden Fehler und Probleme dann eher durch krude knock‑on‑wood‑Workarounds im eigenen Team und zugänglichem Quellcode oder Systembereich behoben, statt sie an der Wurzelursache zu beheben. Man tut sich bei Ihnen schwer mit echter Root Cause Analysis? Voilà!

„I'm coding. Therefore I'm in Panic!“
Szene‑Spruch

Auch erschreckend häufig: Credentials fest verdrahtet im Code. Klar, Lauffähigkeit wird mit diesem Workaround (nämlich um Sorgfalt herum) und weiteren, diesem Prinzip folgenden, schnell und einfach hergestellt. Das Ganze wird dann nur allzu oft von Schulterklopfen des Chefs begleitet: „Wow, flott. Guter Mann!“ (Frauen sind ja leider eher selten im Coding anzutreffen.) Die Katastrophe kommt dann vielleicht irgendwann einmal. Mit etwas Glück (aus seiner Sicht) ist der gelobte Entwickler dann schon mit sehr gutem Arbeitszeugnis in einem anderen Unternehmen tätig. Eine gelebte Compliance‑Pipeline nach DevSecOps wäre hilfreich gewesen. Auch Betrieb und Wartung durch die Maintainer wären weniger holprig. Hätte, hätte...

Beliebt ist auch das Vorgehen mittels Stuck‑States bzw. Deadlocks: Die verschiedenen Teams stellen sich gegenseitig Tickets aus und können stets und mit der Schulter entspannt zuckend argumentieren: „So lange die Anderen das nicht abschließen, kann ich nichts tun“. Eine toxische Kultur ist zu diagnostizieren. Eine Veränderung ist möglich, aber aufwendig.

So manche Führungskraft glaubt irrtümlicherweise auch, Top‑Entwickler im Team zu haben, weil diese gewaltige Schwierigkeiten bewältigen (oder zu bewältigen scheinen). Allerdings gibt es in der Realität nur selten den Bedarf für echtes „Bleeding‑Edge‑Coding“. Sauber aufgesetzt, ist Coding keine Raketenwissenschaft (no rocket science). Schwierigkeiten sind allzu oft hausgemacht. Gutes Coding bedeutet damit, vermeidbare Schwierigkeiten nach Möglichkeit erst gar nicht aufkommen zu lassen: Für einen Teil der zugehörigen Prinzipien stehen Begriffe wie Left‑Shift und microservice‑orientierte Entwicklung. Grundsatz: wehret den Anfängen der Entropie. Damit verdunstet so mancher easy‑going‑KI‑Einsatz zügig ins Nichts. Der Weg zu gutem Code beginnt natürlich mit der Investition in einen guten Abstimmungsprozess aller Interessensgruppen: von Business‑Denkern der Geschäftsleitung über das Betriebsteam bis hin zu Service‑ und Cybersecurity‑Leuten und allen anderen, gefolgt von einem qualitativ hochwertigen Ablauf der Schritte einer individuell angepassten Kombination aus V‑Modell und DevOps. Leider ist auch bei z.B. DevOps manches zu überdenken: Wird z.B. vom „Niederreißen der Mauern zwischen den Silos“ schwadroniert (chakka!), klingt dies zunächst logisch und richtig. Wird eine Gruppe allerdings zu groß, bilden sich natürlicherweise Subgruppen. Eine ganz eigene wir‑gegen‑die‑Dynamik kann sich entwickeln, wenn wir nicht wirtschaftspsychologisch kompetent vorgehen.

Mal nur so gefragt: Wie ist „Clean‑Code“ bei Ihnen genau definiert? Ist die Definition tauglich, gibt sie also Codern eine schnelle, einfache und verbindliche Entscheidungshilfe in nahezu allen Coding‑Lagen?

„Paid to pretend I know what I'm doing“
Szene‑Spruch

Damit sind wir beim zentralen Erfolgsfaktor exzellenten Codings und der Verantwortung des Software‑Engineers: Psychologie, Moderation des Prozesses und manchmal auch ein wenig Mediation. Ein Zusatzstudium als Wirtschaftspsychologe M.Sc. liefert genau diese Zusatzfertigkeiten.

Reden wir über Coding und Mehr!