Blog: Latest Entries (15):


WordPress: Die Lösung für Probleme, die keine sind

bbcode-image


Früher waren Websites erstaunlich schlicht. Ein paar HTML-Dateien, ein bisschen Inhalt, vielleicht ein Downloadbereich und eine Kontaktseite – mehr brauchte es oft nicht. Alles war statisch, direkt greifbar und leicht verständlich. Wenn es irgendwo ein Login-System gab, dann war das meist eine separate Anwendung, auf die einfach verlinkt wurde. Die Website selbst blieb davon unberührt. Das hatte natürlich seine Grenzen, aber es war vor allem eines: einfach.

Wer etwas ändern wollte, öffnete die entsprechenden Dateien und passte den Inhalt direkt an. Es gab keine Templates, keine Widgets, keine abstrahierten Systeme im Hintergrund. Auch Dinge wie suchmaschinenoptimierte URLs spielten kaum eine Rolle. Der Funktionsumfang war überschaubar, aber genau das machte den Umgang damit so effizient. Und wer ein bisschen technisches Verständnis mitbrachte, konnte sich in kurzer Zeit ein eigenes kleines System bauen, das genau diese Anforderungen erfüllte.

Mit der Zeit erkannten viele, dass sich solche Systeme abstrahieren lassen. Es entstanden Content-Management-Systeme, die die Pflege von Inhalten vereinfachen sollten. Doch während die ursprünglichen Websites im Kern oft genauso simpel blieben, entwickelten sich die CMS selbst in eine ganz andere Richtung. Sie wurden größer, komplexer und aufwendiger – nicht selten auch anfälliger.

Ein besonders prägnantes Beispiel dafür ist WordPress. Im Kern bringt es vergleichsweise wenig Funktionalität mit, wird aber durch Plugins zu einem gigantischen Baukasten erweitert. Das Versprechen ist verlockend: Jeder kann alles bauen, ohne wirklich verstehen zu müssen, was im Hintergrund passiert. Doch genau hier beginnt das eigentliche Problem. Aus kleinen Anforderungen werden plötzlich große Systeme, die mit unverhältnismäßigem Aufwand gelöst werden.

Ein einfaches Backup etwa wird zu einer komplexen Plugin-Lösung, obwohl ein kleines Shell-Skript mit zip und mysqldump das gleiche Problem in kürzester Zeit erledigen könnte. Übersetzungen werden über Plugins gelöst, die daran scheitern, dass sich Seiten in verschiedenen Sprachen strukturell leicht unterscheiden. Für Designanpassungen kommen umfangreiche Baukästen zum Einsatz, obwohl ein paar gezielte Änderungen im HTML ausreichen würden – mit dem Nebeneffekt, dass der erzeugte Code ein Vielfaches größer ist als nötig und häufig von unnötigen Abhängigkeiten wie jQuery durchzogen wird.

Natürlich hat dieses System auch seine Vorteile. Es ermöglicht Menschen ohne technischen Hintergrund, komplexe Aufgaben selbst zu erledigen. Ein Umzug der Website wird dann über ein Backup-Plugin abgewickelt – auch wenn das unter Umständen zwanzig Minuten dauert und zusätzliche Hürden mit sich bringt. Wenn etwa der benötigte FTP-Zugang nicht korrekt eingerichtet ist, beginnt schnell ein frustrierendes Hin und Her. Dabei zeigt sich oft, dass der manuelle Weg – Dateien kopieren, Datenbank exportieren und wieder importieren, Konfiguration anpassen – in wenigen Minuten erledigt ist und zuverlässig funktioniert.

Mit der wachsenden Anzahl an Plugins wächst auch die Angriffsfläche. Sicherheit wird zu einem zentralen Thema, und damit auch der Druck, ständig alles aktuell zu halten. Jedes Plugin, jedes Update wird zur potenziellen Fehlerquelle. Es entsteht eine gewisse Angst, etwas zu übersehen oder durch ein Update etwas zu zerstören. Gleichzeitig laufen viele Systeme auf veralteten Grundlagen, etwa älteren PHP-Versionen, weil die Sorge besteht, dass ein Upgrade bestehende Funktionen beeinträchtigen könnte. Dass sich solche Probleme meist beheben lassen oder Änderungen rückgängig gemacht werden können, gerät dabei oft in den Hintergrund.

Am Ende entsteht ein paradoxes Bild: Für kleine, eigentlich triviale Probleme werden große, komplexe Lösungen eingesetzt. Die Betreiber der Websites nehmen das als gegeben hin, ohne zu hinterfragen, ob der zugrunde liegende Bedarf diesen Aufwand überhaupt rechtfertigt. Für statische oder nur leicht dynamische Websites ist ein System wie WordPress häufig überdimensioniert. Es verbraucht Ressourcen und erzeugt Verwaltungsaufwand, obwohl ein leichtgewichtiges CMS oder sogar eine schlanke Eigenlösung mit überschaubarem Code völlig ausreichen würde.

Selbst die Verwendung einer Datenbank ist in vielen Fällen fragwürdig, wenn die Inhalte am Ende ohnehin aus einem Cache ausgeliefert werden. Eine einfache dateibasierte Lösung könnte hier genauso gut funktionieren – mit deutlich weniger Komplexität.

Trotz all dieser Punkte bleibt WordPress für viele die erste Wahl. Es hat sich als Standard etabliert, unabhängig davon, ob es für den jeweiligen Anwendungsfall wirklich geeignet ist. Die Folge sind höhere Kosten, mehr Wartungsaufwand und unnötige Komplexität. Und so bleibt am Ende oft der Eindruck, dass hier Lösungen für Probleme geschaffen werden, die in ihrer ursprünglichen Form nie besonders groß waren.

Andere Abteilungen sind nicht dumm

bbcode-image


Ich habe über dieses Thema schon einmal geschrieben, damals vor allem im Kontext von Agenturkunden. Doch ein aktueller Anlass bringt mich dazu, es noch einmal aufzugreifen – diesmal mit Blick auf die Zusammenarbeit innerhalb derselben Firma. Genauer gesagt: auf das Verhältnis zwischen IT oder Entwicklung und allen anderen Abteilungen.

Was mich immer wieder stört, ist diese Haltung, die man leider nicht selten erlebt: Entwickler oder ganze IT-Teams verhalten sich, als wären sie die einzigen wirklich intelligenten Menschen im Unternehmen. Alles, was nicht direkt aus ihrer Welt stammt, wird schnell als unzureichend oder inkompetent abgestempelt. Anforderungen seien nicht detailliert genug, auf Rückfragen kämen keine sofortigen Antworten, sondern erst nach interner Abstimmung. Prozesse seien unklar, Entscheidungen nicht nachvollziehbar, und überhaupt – warum kennt sich die Leitung eigentlich nicht technisch bis ins letzte Detail aus?

Diese Kritikpunkte tauchen immer wieder auf. Doch die Art und Weise, wie sie vorgetragen werden, ist oft das eigentliche Problem. Dahinter steckt nicht selten eine übersteigerte Arroganz, die andere Mitarbeiter direkt oder indirekt abwertet. Es wird sich offen gewundert, wie ein Unternehmen mit solchen Leuten überhaupt funktionieren kann. Und nicht selten wird die Diskussion sogar persönlich.

Wer so denkt und handelt, hat meiner Meinung nach nicht nur ein zwischenmenschliches Problem, sondern auch ein grundlegendes Missverständnis davon, wie Arbeitswelt funktioniert. Ein IT-Leiter muss kein Top-Entwickler sein. Seine Aufgabe ist es, Verantwortung zu übernehmen, wirtschaftlich zu planen und Entscheidungen zu treffen. Dafür gibt es Entwickler im Team – genau wie es in anderen Abteilungen Experten gibt, die ganz andere Fähigkeiten mitbringen.

Denn genau das wird oft vergessen: Die Kompetenzen in anderen Bereichen sind nicht geringer, sie sind einfach anders gelagert. Marketing, Vertrieb, HR oder Controlling folgen eigenen Logiken, sprechen eigene Sprachen und lösen Probleme auf ihre Weise. Und ganz ehrlich: Jeder Entwickler, der behauptet, sämtliche Abläufe in der IT vollständig zu durchdringen, hat wahrscheinlich selbst schon die Hälfte vergessen oder nie im Detail verstanden.

Am Ende sitzen überall Fachkräfte. Menschen, die in ihrem Bereich deutlich mehr wissen als man selbst. Und wenn angeblich alle anderen so unfähig sind – wie kommt es dann, dass das Unternehmen erfolgreich genug ist, um sich teure Entwickler leisten zu können? Diese Frage sollte man sich ruhig öfter stellen.

Hinzu kommt, dass Entscheidungen im Unternehmen selten rein technisch getroffen werden. Es geht um Budgets, Risiken, Zeitpläne und strategische Überlegungen. Die „beste“ technische Lösung ist nicht immer die sinnvollste. Das zu verstehen, braucht Erfahrung – und oft auch den Blick über den eigenen Tellerrand hinaus.

Interessanterweise ändert sich die Perspektive häufig, je weiter man in seiner Karriere kommt. Mit wachsender Verantwortung wächst auch das Verständnis für die Komplexität von Entscheidungen und für die Fähigkeiten anderer. Dinge, die vorher unverständlich oder „dumm“ wirkten, ergeben plötzlich Sinn.

Als Entwickler ist man letztlich auch nur ein Teil des Ganzen. Man arbeitet mit den Informationen, die man bekommt, und bewegt sich innerhalb eines Systems, das von vielen anderen geprägt wird. Wer wirklich besser werden will, sollte anfangen, mit anderen Abteilungen zusammenzuarbeiten, ihre Denkweisen zu verstehen und ihre Sprache zu lernen.

Denn genau darin liegt der Schlüssel: Wenn jemand versucht, „IT zu sprechen“, klingt das für Entwickler oft unbeholfen. Aber das Gleiche gilt umgekehrt. Wer sich die Mühe macht, die Sprache anderer Disziplinen zu lernen, merkt schnell, wie viel Wissen und Intelligenz dort steckt.

Oder, um es mit einem Zitat aus der Serie Modern Family zu sagen: „Do you even know how smart I am in Spanish?“

Gedanken zu Kündigungen in Zeiten von KI

bbcode-image


Über die letzten Jahre war ich mehrfach an Kündigungen beteiligt, und auch wenn jeder einzelne Fall unterschiedlich war, haben sich gewisse Muster immer wieder gezeigt. Es ging selten um fehlende Programmierfähigkeiten. Viel häufiger waren es mangelnde Erfahrung für die jeweilige Position, ein nicht passendes Mindset oder – gerade in schnelllebigen Agenturumfeldern – eine fehlende Stressresistenz. Was dabei jedoch nie gefehlt hat, waren Gespräche. Es wurde Feedback gegeben, Erwartungen wurden klar formuliert und Probleme offen angesprochen. Gleichzeitig war aber auch oft spürbar, dass gewisse Dinge nicht kurzfristig veränderbar sind. Mindset, Zuverlässigkeit oder Kommunikationsfähigkeit lassen sich nicht einfach „nachschulen“.

Trotzdem gab es immer eine gewisse Sicherheit im Hintergrund. Die meisten dieser Personen hatten zuvor gearbeitet und konnten grundsätzlich auf einem bestimmten Niveau bestehen. Wenn jemand beispielsweise als Senior eingestellt wurde, sich aber eher als Junior entpuppte, war eine Trennung zwar unangenehm, aber kein Drama. Der Markt war aufnahmefähig, insbesondere für Entwickler. Selbst Junior-Positionen waren oft verfügbar, und die Gewissheit, dass jemand wieder unterkommen würde, hat solche Entscheidungen erleichtert.

Vor Kurzem gab es wieder einen solchen Fall. Die Situation war relativ eindeutig. Es gab eine konsequente Weigerung, grundlegende Tools wie Confluence oder Jira zu nutzen. Commits ins Git-Repository erfolgten nur nach mehrfacher Aufforderung, oft mit der Begründung, dass der Code ja noch nicht fertig sei – obwohl genau darin der Sinn moderner Versionskontrolle liegt. Aufgaben dauerten um ein Vielfaches länger als erwartet, und gleichzeitig bestand eine klare Ablehnung gegenüber dem Einsatz von AI-Agents in der Entwicklung. Dazu kamen fehlende Soft Skills, teils grenzwertiges Verhalten gegenüber anderen Führungskräften und eine insgesamt mangelnde Zuverlässigkeit. Einsicht war nicht vorhanden.

Die Besonderheit in diesem Fall lag darin, dass die Person formal auf Abteilungsleiterebene agierte – weniger aus Qualifikation heraus, sondern weil zu einem bestimmten Zeitpunkt schlicht niemand anderes verfügbar war. Doch ein Titel ersetzt keine Erfahrung. Ein Junior-Entwickler wird nicht plötzlich zum CTO, nur weil es organisatorisch gerade passt.

Was mich jedoch wirklich überrascht hat, war die Reaktion auf die Kündigung. Die Aussage, man würde als Entwickler ohnehin sofort wieder einen Job finden, kam mit einer Selbstverständlichkeit, die ich so nicht mehr für realistisch halte. Noch irritierender war die Ergänzung, man könne ja sonst einfach ins Projektmanagement wechseln. Diese Haltung unterschätzt gleich zwei Dinge fundamental. Zum einen sind gute Projektmanager extrem selten, und ihre Arbeit ist alles andere als ein Ausweichplan. Zum anderen basiert erfolgreiches Projektmanagement genau auf den Fähigkeiten, die hier zuvor gefehlt haben: Kommunikation, Struktur, Verlässlichkeit und der souveräne Umgang mit Tools wie Jira.

Ich habe in meiner Laufbahn nur eine Handvoll wirklich herausragender Projektmanager erlebt, obwohl ich mit vielen gearbeitet habe. Diese Rolle erfordert ein tiefes Verständnis für Menschen, Prozesse und Prioritäten. Sie ist kein Auffangbecken für gescheiterte Entwicklerkarrieren.

Auch die Annahme, dass Entwickler grundsätzlich immer gefragt sind, beginnt zu bröckeln. Wer moderne Entwicklungstools ablehnt und stattdessen darauf beharrt, dass sich alles auch mit Word, Excel und einem geteilten Laufwerk lösen lässt, sendet klare Signale. Spätestens in Bewerbungsgesprächen, an denen erfahrene Entwickler beteiligt sind, fallen solche Haltungen schnell auf. Ebenso entwickelt man ein Gespür dafür, wie realistisch die Erwartungen eines Kandidaten sind. Wenn jemand davon ausgeht, dass jedes Ticket vollständig ausgearbeitet ist, umfassende Dokumentation vorliegt und gleichzeitig eine hundertprozentige Testabdeckung existiert, dann zeigt das weniger Professionalität als vielmehr eine fehlende Nähe zur Realität moderner Softwareentwicklung.

Interessanterweise ist Programmieren selbst nach wie vor selten das eigentliche Problem. Wenn jedoch eine vergleichsweise günstige Tool-Subscription die Produktivität eines Entwicklers um ein Vielfaches steigern könnte und dieser Mehrwert nicht genutzt wird, dann ist das ein deutliches Warnsignal. Genau hier setzt auch der Einfluss von KI an. Die aktuellen Entwicklungen verschieben die Anforderungen immer stärker in die Bereiche, in denen viele Entwickler traditionell Schwächen haben. Kommunikation wird wichtiger, Dokumentation unverzichtbar, und die Geschwindigkeit sowie Qualität in der Umsetzung steigen durch den Einsatz von KI-gestützten Werkzeugen erheblich. Gleichzeitig gewinnen das Verständnis für das jeweilige Unternehmen und seine Produkte sowie die Fähigkeit, sinnvolle Tests zu schreiben, weiter an Bedeutung.

Diese Entwicklung macht manche Profile schlicht untragbar für moderne Teams. Und auch wenn es hart klingt, hoffe ich in diesem konkreten Fall, dass nicht sofort wieder eine vergleichbare Position gefunden wird. Nicht aus Missgunst, sondern weil Entwicklung Zeit braucht. Wer noch nicht so weit ist, sollte die Chance bekommen, in einem passenden Umfeld zu wachsen. Unternehmen, die bewusst Junior-Entwickler einstellen und fördern, spielen dabei eine entscheidende Rolle. Nur so entsteht langfristig die Erfahrung, die später notwendig ist, um höhere Positionen nicht nur zu erreichen, sondern auch erfolgreich auszufüllen.

Tokenmaxxing: Kosten über Resultate

bbcode-image


In den letzten Tagen bin ich auf einen interessanten Begriff gestoßen: Tokenmaxxing. Gelesen habe ich darüber in einem Artikel auf Golem, und die Grundidee hat mich sofort nachdenklich gemacht. Vereinfacht gesagt geht es dabei darum, möglichst viele Tokens bei der eigenen Arbeit mit KI-Tools zu generieren. Hohe Tokenzahlen bedeuten schließlich hohe Kosten – und in manchen Kreisen scheint genau das zunehmend mit Produktivität oder intensiver Nutzung von KI im Job gleichgesetzt zu werden.

Solche extremen Werte entstehen vor allem dann, wenn große Loops laufen gelassen werden oder riesige Kontexte wie komplette Codebasen in Prompts geschoben werden. Auch der parallele Einsatz vieler Agenten treibt den Tokenverbrauch schnell nach oben. Dabei dürfte es zwangsläufig zu Redundanzen kommen, weil mehrere Prozesse ähnliche Aufgaben bearbeiten oder sich gegenseitig überholen. Rein technisch ist das nachvollziehbar. Fragwürdig wird es jedoch, wenn daraus Leistungskennzahlen abgeleitet werden.

Denn ob jemand monatlich 150.000 Dollar an Tokenkosten verursacht, sagt zunächst einmal sehr wenig über seine tatsächliche Produktivität oder sein Können aus. Diese Denkweise erinnert stark an ein altes Paradigma aus der Softwareentwicklung: die Bewertung von Entwicklerleistung anhand geschriebener Codezeilen. Schon vor Jahrzehnten wurde erkannt, dass viele Zeilen Code keineswegs automatisch für Qualität stehen – häufig sogar für das Gegenteil. Guter Code ist optimiert, übersichtlich und wartbar. Und oft ist er gerade deshalb so gut, weil er so kurz wie möglich ist.

Im Grunde geht es um eine Haltung zur Problemlösung. Wer sich Zeit nimmt, nachzudenken und eine durchdachte Lösung zu entwickeln, erreicht sein Ziel meist mit weniger Aufwand – und eben auch mit weniger Tokens. Wer hingegen versucht, jedes Problem mit möglichst viel generiertem Output zu erschlagen, verliert schnell den Überblick. Hohe Tokenzahlen zeigen dann vor allem eines: dass KI intensiv genutzt wird. Sie zeigen jedoch nicht, ob sie sinnvoll eingesetzt wird. Im Gegenteil, bei sehr großen Mengen könnte man sogar vermuten, dass die Kontrolle über den Entwicklungsprozess teilweise verloren gegangen ist.

Hinzu kommt eine Nachhaltigkeitsperspektive, die man nicht ignorieren sollte. Unnötig Geld und Energie zu verbrennen, kann kaum ein sinnvolles Ziel sein – weder für Einzelpersonen noch für Unternehmen, die langfristig denken wollen. Gleichzeitig ist schwer einzuschätzen, wie verbreitet dieses Tokenmaxxing tatsächlich ist. Vielleicht handelt es sich nur um einzelne Extremfälle oder sogar um eine Form von Trolling. Ohne die konkreten Anwendungsfälle zu kennen, lässt sich auch nicht beurteilen, ob der hohe Verbrauch in bestimmten Szenarien gerechtfertigt oder sogar wirtschaftlich sinnvoll ist.

Für den normalen Entwickler sollte das Ziel jedenfalls ein anderes sein. Es geht darum, mit möglichst geringem Aufwand maximale Ergebnisse zu erzielen. Effizienz bedeutet nicht, möglichst viele Ressourcen zu verbrauchen, sondern sie klug einzusetzen. Firmen, die glauben, allein aus Tokenzahlen etwas Positives über Leistung oder Fortschritt ablesen zu können, wirken dabei fast ein wenig wie Relikte aus einer anderen Zeit. Modernität zeigt sich nicht darin, neue Kennzahlen einzuführen, sondern darin, die richtigen Fragen zu stellen.

OpenCode mit Ollama.. einfach!

Ich geh einfach mal davon aus, dass Ollama in der einen oder anderen Variante schon läuft. Dabei ist es egal ob es nativ auf einem Rechner läuft oder in einem Docker-Container.
Als Model nutzen wir Qwen3:8b. Wir starten das Model in Ollama via


ollama run qwen3:8b


darin ändern wir num_ctx und speichern es unter neuen Namen ab. Das ist EXTREM wichtig, weil sonst die Agentic Tools (z.B. schreiben von Dateien) nicht funktionieren werden.. ich habe es probiert.


/set parameter num_ctx 16384
/save qwen3:8b-16k
/bye


Nun installieren wir OpenCode (Linux):


curl -fsSL https://opencode.ai/install | bash


Und legen die Config (~/.config/opencode/config.json) an:


{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"options": {
"baseURL": "http://your_ollama_server:11434/v1"
},
"models": {
"qwen3:8b-16k": {
"tools": true
}
}
}
}
}


Nun kann man OpenCode mit opencode starten und das Model per /models auswählen und loslegen.

gemma:latest funktioniert auch, wenn man die num_ctx Anpassung vornimmt.

KI kann unsere Standards nicht einhalten

bbcode-image


Manchmal macht es tatsächlich Spaß, mit anderen Menschen über KI in der Softwareentwicklung zu diskutieren. Besonders dann, wenn man auf Positionen trifft, die unterschiedlicher kaum sein könnten. Auf der einen Seite stehen diejenigen, die mit KI experimentieren, ihre Möglichkeiten austesten und versuchen, sie sinnvoll in den Entwicklungsalltag zu integrieren. Auf der anderen Seite gibt es immer noch viele, die jede Nutzung von KI kategorisch ablehnen. Für sie ist das Thema im Grunde bereits entschieden: KI taugt nichts, produziert keinen brauchbaren Code und spart am Ende ohnehin keine Zeit.

Interessanterweise gehen viele dieser Meinungen mit einer gewissen Verweigerungshaltung einher. Häufig hört man, dass es sich gar nicht lohne, KI überhaupt auszuprobieren. Allein das Testen sei bereits Zeitverschwendung, schließlich gebe es genügend Argumente, die angeblich belegen würden, dass KI ohnehin nichts taugt. Besonders oft fällt in diesem Zusammenhang das Argument, dass der durch KI erzeugte Code ja überprüft werden müsse. Dieser zusätzliche Review-Aufwand würde den möglichen Zeitgewinn direkt wieder zunichtemachen.

Dabei wird implizit eine bemerkenswerte Annahme getroffen: dass menschliche Entwickler offenbar keinen Code produzieren, der überprüft werden muss. Als wären Code Reviews nur deshalb erfunden worden, weil es jetzt KI gibt. In dieser Logik wäre der Code von Menschen grundsätzlich korrekt, während nur KI fehlerhaften Code erzeugt. Die Realität in der Softwareentwicklung sieht allerdings deutlich anders aus. Code Reviews existieren nicht, weil irgendjemand in der Vergangenheit KI vorhergesehen hat, sondern weil jede Quelle von Code potenziell fehleranfällig ist. Ganz egal, ob dieser Code von einer Maschine oder einem Menschen stammt.

Meine eigenen Erfahrungen zeigen ziemlich klar, dass Menschen sehr viele Fehler machen. Das ist völlig normal und gehört zum Entwicklungsprozess dazu. Jeder Entwickler hat schon schlechten Code geschrieben, oft ohne es in dem Moment zu merken. Im Vergleich dazu schneidet eine KI erstaunlich häufig ziemlich gut ab. Der entscheidende Unterschied liegt dabei weniger in der Fehlerfreiheit als in der Geschwindigkeit. Wenn ein Mensch einen Fehler macht, kann es Stunden dauern, bis er entdeckt und korrigiert wird. Mit KI laufen diese Iterationen oft innerhalb weniger Minuten ab. Fehler entstehen auf beiden Seiten, aber die Geschwindigkeit, mit der man sie finden und beheben kann, verändert sich drastisch.

Ein weiteres häufiges Argument lautet, dass der Review von KI-Code besonders aufwendig sei, weil bestehende Konzepte und Teamstandards nicht eingehalten würden. Die KI kenne diese Regeln schließlich nicht. Interessanterweise wird dabei selten erwähnt, dass neue Entwickler diese Standards ebenfalls nicht automatisch kennen. Niemand beginnt einen neuen Job und weiß intuitiv, welche internen Regeln in einem Team gelten. Auch Menschen müssen diese erst lernen, meistens anhand von Dokumentationen oder durch Gespräche mit Kollegen.

Genau dieselben Informationen könnte man einer KI ebenfalls geben. Tatsächlich liest eine KI ein solches Dokument sogar deutlich schneller als ein Mensch. Sollte es allerdings gar keine dokumentierten Standards geben, liegt das Problem vermutlich an einer ganz anderen Stelle. In vielen Teams existieren diese Regeln nämlich nur in den Köpfen einzelner Entwickler. Sobald jemand Neues hinzukommt, beginnt das mühsame Entschlüsseln dieser impliziten Erwartungen. Dass eine KI daran scheitert, zeigt dann weniger eine Schwäche der KI als eine Schwäche der vorhandenen Prozesse.

Oft wird auch argumentiert, dass eine KI gar nicht wissen könne, welche zusätzlichen Informationen in Meetings oder Calls besprochen wurden. Aber dieses Problem betrifft jeden, der an einem Meeting nicht teilgenommen hat. Wenn Informationen nicht festgehalten werden, kann niemand darauf zugreifen. Wer daraus ableitet, dass nur KI dadurch ein schlechter Entwickler wäre, müsste konsequenterweise auch jedem Kollegen, der einmal einen Termin verpasst hat, dieselbe Unfähigkeit unterstellen. In der Praxis wäre es ohnehin sinnvoller, solche Meetings zu dokumentieren oder direkt automatisch zusammenfassen zu lassen.

Ein besonders unterhaltsamer Teil dieser Diskussionen dreht sich um Coding-Standards und Code Style. Ich habe im Laufe meiner Karriere an genügend Code-Style-Meetings teilgenommen, um eine gewisse Skepsis gegenüber deren tatsächlichem Nutzen entwickelt zu haben. Häufig werden solche Meetings von jemandem initiiert, dessen persönliches ästhetisches Empfinden durch den Code anderer Entwickler beleidigt wurde. Diese Person erklärt dann zunächst ausführlich, wie wichtig ein einheitlicher Coding Style für jedes Team sei.

Darauf folgt meist eine Liste dramatischer Szenarien darüber, was alles passieren könnte, wenn man sich nicht darum kümmert. Der Code wäre angeblich schon nach wenigen Monaten völlig unlesbar. Danach werden Beispiele präsentiert, wie man Dinge „richtig“ macht. Ich habe tatsächlich einmal erlebt, dass ernsthaft gefordert wurde, die Einrückung im Code von vier auf drei Spaces zu ändern, weil dies angeblich deutlich besser lesbar sei. Nicht zwei, nicht vier – exakt drei.

Unternehmen lieben solche Initiativen, weil sie den Eindruck vermitteln, dass damit automatisch die Codequalität steigt und Fehler drastisch reduziert werden. Am Ende schreibt jemand ein Dokument mit den neuen Regeln. Dieses Dokument wird anschließend kaum noch gelesen, während es von seinem ursprünglichen Autor gelegentlich weiter gepflegt wird. In Code Reviews fallen Verstöße selten auf, weil auch der Reviewer das Dokument nie wirklich studiert hat. Manchmal gibt es dann irgendwann einen automatischen Reformat, und der Code landet wieder beim Standardstil der verwendeten IDE.

Ich habe in solchen Situationen oft gefragt, warum man bei PHP nicht einfach sagt, dass man sich an PSR-12 halten soll. Eine kurze Nachricht im Chat würde ausreichen, und jeder wüsste sofort, woran er ist. Die Reaktionen zeigen dann meist recht schnell, dass es selten wirklich um Verbesserungen ging. Häufig stehen persönliche Vorlieben oder ein gewisses Bedürfnis nach Einfluss im Mittelpunkt.

Genau hier liegt übrigens eine der Stärken von KI. Man gibt ihr einen etablierten öffentlichen Coding-Standard und lässt zusätzlich eine Pipeline laufen, die diesen Stil automatisch überprüft und erzwingt. Die KI kann sich problemlos daran halten oder bestehenden Code entsprechend anpassen. Sobald die Regeln klar formuliert sind, funktioniert das erstaunlich zuverlässig.

Grundsätzlich gilt: Wenn Prozesse sauber dokumentiert sind, kann eine KI hervorragend damit arbeiten. Wenn stattdessen viele Dinge nur im Kopf einzelner Entwickler existieren, dann deckt eine KI lediglich bereits vorhandene strukturelle Probleme auf. In gewisser Weise verhält sich die Einführung von KI sehr ähnlich wie das Onboarding eines neuen Junior Developers. Wenn ein Team daran scheitert, einer KI die notwendigen Informationen bereitzustellen, hätte es vermutlich auch große Schwierigkeiten gehabt, einen neuen Entwickler sinnvoll einzuarbeiten.

Natürlich kostet die Nutzung von KI Zeit. Man muss Prompts formulieren, Ergebnisse prüfen und manchmal nachjustieren. Aber genau diese Aufwände entstehen auch bei menschlicher Zusammenarbeit. Oft sogar in größerem Umfang. Gleichzeitig bringt KI einen enormen Geschwindigkeitsvorteil mit sich. Code entsteht in Sekunden oder Minuten statt in Stunden. Dieser Code ist nicht immer perfekt, aber perfekt war Code früher auch nicht.

Am Ende wirken viele der vorgebrachten Argumente weniger wie fundierte Kritik und mehr wie Ausreden. Dahinter steckt oft die Hoffnung, dass sich das Thema irgendwie von selbst erledigt, wenn man lange genug abwartet. Stattdessen wäre es wahrscheinlich sinnvoller, sich aktiv damit auseinanderzusetzen und die Entwicklung mitzugestalten. Denn wenn es berechtigte Bedenken gibt, dann lassen sie sich nur lösen, wenn man beginnt, mit der Technologie zu arbeiten – nicht, wenn man sie ignoriert.

Das kann ICH alles besser! – Wenn Selbstüberschätzung zum Unternehmensrisiko wird

bbcode-image


Es gibt Kollegen, die misstrauen grundsätzlich allem, was sie nicht selbst gemacht haben. Dabei spielt es keine Rolle, ob eine Lösung von anderen Teammitgliedern stammt oder extern eingekauft wurde. Was nicht aus der eigenen Feder kommt, wird kritisch beäugt, vorschnell abgewertet oder direkt als mangelhaft abgestempelt. Besonders häufig zeigt sich dieses Verhalten im technischen Umfeld, wenn es um Software oder Hardware geht. Programme werden als fehlerhaft und unoptimiert bezeichnet, ohne dass sie jemals ernsthaft getestet oder analysiert wurden. Geräte gelten als unzuverlässig oder schlecht verarbeitet, weil einmal etwas nicht reibungslos lief. Aus einer einzelnen Beobachtung wird ein grundsätzliches Problem konstruiert.

Statt sich strukturiert mit möglichen Ursachen auseinanderzusetzen oder nüchtern nach Alternativen zu suchen, beginnt dann das große Herumbasteln. Es wird geschraubt, getauscht, umkonfiguriert und optimiert, um vermeintliche Unzulänglichkeiten zu beheben, die in dieser Form oft gar nicht existieren. Ein besonders anschauliches Beispiel war ein Mini-PC, der beim Kopieren sehr großer Dateien nicht den erhofften Datendurchsatz erreichte. Dabei wurde mehrfach erklärt, dass solche Szenarien im normalen Office-Alltag praktisch nicht vorkommen und sich bislang kein einziger Nutzer über die Performance beschwert hatte. Dennoch wurde aus diesem Einzelfall kurzerhand geschlossen, dass die gesamte Baureihe fehlerhaft sei und alle Geräte bald ausfallen würden.

Was folgte, war eine regelrechte Optimierungsodyssee. Die Wärmeleitpaste wurde ersetzt, weil es vermeintlich bessere Varianten gäbe. Mehrere zusätzliche SSDs wurden angeschafft und getestet, obwohl die eingebaute OEM-SSD für typische Büroaufgaben vollkommen ausreichend dimensioniert war. Die WLAN-Karte wurde ausgebaut, da sie als potenzielle Stabilitätsursache vermutet wurde. Das Kühlkonzept wurde als grundsätzlich schlecht durchdacht bezeichnet, Teile davon wurden mit Werkzeug entfernt und später provisorisch wieder eingebaut. Selbst nach weiteren Anpassungen und erneutem Austausch der Wärmeleitpaste blieb das Ziel, bessere Benchmarkergebnisse zu erzielen, insbesondere in synthetischen Tests wie Cinebench, die für einen Office-PC keinerlei Relevanz im Alltag haben. Am Ende zeigte das Gerät tatsächlich Probleme, doch nach so vielen Eingriffen war kaum noch nachvollziehbar, wodurch sie verursacht wurden. Ein Austausch gegen eine bewährte Alternative wie eine HP Z2 G1a wurde kategorisch abgelehnt, da der ursprüngliche Einzelfall inzwischen als Beweis für die generelle Untauglichkeit von Mini-PCs interpretiert wurde.

Ein ähnliches Muster zeigte sich bei einer Legacy-Software. Die Datenbank sei falsch aufgebaut, die Anbindung schlecht umgesetzt, alles voller Fehler. Den Entwicklern wurde unterstellt, sie hätten keine Ahnung und seien nicht in der Lage, bestehende Probleme zu beheben. Die gesamte Konfiguration wurde als unprofessionell dargestellt. Also wurde eine eigene Konfiguration entwickelt, vieles neu aufgesetzt und umgebaut. Doch nach umfangreichen Tests zeigte sich, dass die vorgenommenen Änderungen keinerlei messbare Verbesserung brachten. Die ursprüngliche Lösung funktionierte genauso gut oder schlecht wie zuvor.

Grundsätzlich ist es positiv, wenn Probleme angegangen und Lösungen gesucht werden. Doch nicht jedes kleine Symptom rechtfertigt es, ein gesamtes Produkt oder eine komplette Lösung als grundsätzlich fehlerhaft zu brandmarken. Wenn außer einer einzelnen Person niemand Probleme wahrnimmt, spricht vieles dafür, dass es sich nicht um ein systemisches, sondern um ein situatives Thema handelt. Ein sehr hochbezahlter Entwickler sollte seine Zeit nicht damit verbringen, verschiedene Wärmeleitpasten durchzutesten, um für einen Office-Rechner marginal bessere Benchmarks zu erzielen. Investierte Arbeitszeit muss in einem sinnvollen Verhältnis zum Nutzen stehen. Ressourcen sollten dort eingesetzt werden, wo sie echten Mehrwert schaffen, und nicht zur Absicherung theoretischer Grenzfälle, die im realen Betrieb nie auftreten.

Die Folgen eines solchen Verhaltens sind gravierend. Schuld wird reflexartig bei anderen gesucht, externe Partner werden unnötig unter Druck gesetzt, um Notfälle zu verhindern, die mit hoher Wahrscheinlichkeit nie eintreten werden. Es wird Geld verbrannt, ohne dass ein messbarer Impact entsteht. Gleichzeitig wird die Arbeit anderer abgewertet, obwohl sie nach bestem Wissen und Gewissen und auf Basis sauberer Tests durchgeführt wurde. Wenn ständig behauptet wird, alles ließe sich besser machen, ohne dass sich diese Behauptung jemals belegen lässt, verliert Kritik an Glaubwürdigkeit. Am Ende weiß niemand mehr, ob Einwände berechtigt sind oder lediglich Ausdruck persönlicher Selbstüberschätzung.

Besonders problematisch wird dieses Verhalten in Führungspositionen. Wer grundsätzlich niemandem im Team vertraut, wird jede Arbeit hinterfragen und kleinreden. Statt Verantwortung zu delegieren, wird alles an sich gezogen, häufig mit dem Ergebnis, dass schlechtere Lösungen entstehen, als es mit etablierten Produkten oder externem Know-how der Fall gewesen wäre. Hinzu kommen unnötige Ausgaben, weil bewährte Lösungen aus Prinzip abgelehnt werden, obwohl sie anderswo seit Jahren stabil funktionieren. Führung bedeutet jedoch, Vertrauen zu schenken, Kompetenzen zu bündeln und die Stärken anderer anzuerkennen, nicht alles selbst besser wissen zu wollen.

Am Ende bleibt eine einfache Erkenntnis: Man kann nicht alles besser. Kollegen und externe Partner arbeiten in der Regel nach bestem Wissen und Gewissen. Ohne konkreten Anlass ihre Arbeit grundsätzlich infrage zu stellen, ist nicht nur unfair, sondern auch ineffizient. Wer behauptet, alles besser zu können, muss dies auch nachweislich belegen. Wenn jedoch trotz großer Worte keine besseren Ergebnisse entstehen, sollte man eher an der eigenen Selbstwahrnehmung arbeiten als an der Hardware. Und wer dauerhaft Misstrauen sät, unnötige Kosten verursacht und etablierte Lösungen aus Prinzip ablehnt, sollte keine Führungsverantwortung tragen, denn eine solche Haltung führt selten zu besseren Ergebnissen – aber fast immer zu einem zerrütteten Team.

Sind lokale große Server tot?

bbcode-image


Ich sitze gerade in einer Umgebung, die sinnbildlich für ein ganz bestimmtes IT-Zeitalter steht. In einem kleinen Labor werkeln drei ziemlich große ESXi-Hosts von VMware, flankiert von mindestens ebenso vielen NAS-Systemen von QNAP. In diesen Racks steckt unglaublich viel Geld. Viel Blech, viel RAM, viele SAS-SSDs, redundante Netzteile, dedizierte RAID-Controller – alles, was man sich vor ein paar Jahren unter „Enterprise“ vorgestellt hat.

Und ja, damals war das beeindruckend. Viele Windows-VMs, sauber getrennt, alles hochverfügbar, alles virtualisiert. Das war State of the Art.

Nur kam dann die Ryzen- und Epyc-Zeit.

Hier steht inzwischen als Testsystem ein unscheinbarer Mini-PC, eine Leihgabe eines Software-Anbieters. Ein kleiner Kasten mit Ryzen-CPU, 96 GB DDR5-RAM und schnellen NVMe-SSDs. Nichts davon klingt nach Rechenzentrum. Aber egal, wie viele CPUs, wie viel RAM oder wie viele SAS-SSDs ich einer VM auf den großen Hosts zuweise – an die gefühlte und messbare Performance dieses kleinen Ryzen-Systems kommt keine davon heran. Nicht, weil die VM schlecht konfiguriert wäre, sondern weil der Unterbau limitiert. Alte CPUs von 2017 oder 2019, Storage-Anbindungen, die nie wirklich auf NVMe-Niveau waren, gewachsene Strukturen, die auf maximale Konsolidierung statt auf maximale Performance ausgelegt sind.

Cloud war übrigens auch mal ein Thema. Noch bevor ich dazu gestoßen bin, wurden die Pläne wieder beerdigt. Zu teuer, zu komplex, zu viele offene Fragen. Also blieb alles on-prem – aber eben in einem Denkmuster, das stark in den 2010ern verwurzelt ist.

Dicke ESXi-Server mit einem Zoo aus Windows-VMs waren lange total in. Jede Anwendung bekam ihren eigenen Windows Server. Eine MongoDB hier, eine Firebird-Datenbank dort, noch ein Applikationsserver daneben. Alles sauber getrennt, alles ordentlich lizenziert, alles virtuell – aber auch alles schwerfällig. Heute frage ich mich ernsthaft, warum eine MongoDB oder eine Firebird-Datenbank zwingend auf einem eigenen Windows-Server laufen muss, wenn sie sich technisch problemlos in getrennten Docker-Containern auf einem schlanken Linux-Host betreiben ließe. Containerisierung ist kein Hype mehr, sondern Alltag. Docker-Setups sind reproduzierbar, leichtgewichtig und in vielen Fällen performanter als klassische VM-Monolithen.

Stattdessen werden weiter große Server gekauft. Schwer, teuer, beeindruckend auf dem Datenblatt – aber mit erstaunlich langsamen CPUs. Die „neueste“ CPU-Generation hier stammt von 2019, der Rest von 2017. In rechenintensiven OCR-Anwendungen würde vermutlich schon ein mittelmäßiger AMD EPYC 4005 die teuren Xeons deutlich abhängen. Und wenn man dann noch an eine kleine GPU wie die NVIDIA A2 mit 16 GB VRAM denkt, wird klar, wie viel Potenzial hier brachliegt – nicht aus Mangel an Budget, sondern aus Mangel an Paradigmenwechsel.

Refurbished-Hardware spart auf dem Papier Geld, und ich bin grundsätzlich ein Freund davon. Aber man landet schnell an einem Punkt, an dem günstige, moderne Systeme die objektiv bessere Wahl gewesen wären. Gerade bei den heutigen Speicherpreisen relativiert sich vieles. Server-Hardware ist teuer, keine Frage. Doch wenn man Systeme mit fest verbautem, aber schnellem Speicher betrachtet, wird es plötzlich interessant. Und ein Server ohne NVMe-SSDs fühlt sich inzwischen schlicht nicht mehr zeitgemäß an.

Für mich sind die Zeiten der riesigen, alles-konsolidierenden Server weitgehend vorbei. Ich würde lieber mehrere kompakte Workstation-Systeme wie den HP Z2 G1a ins Rack stellen, jeweils mit 128 GB schnellem RAM und NVMe-Storage, dazu sauber angebundener Blockspeicher von den NAS-Systemen. Anwendungen granular verteilen, Dienste klar trennen, auf schlanke Lösungen wie Docker setzen, wo immer es geht. Ein Fileserver muss nicht zwangsläufig eine Windows-VM sein, wenn das NAS selbst diese Aufgabe solide übernehmen kann. Warum also noch Maschinen mit 3 TB RAM und vier CPUs betreiben, die im Kern nur Windows-VMs vorhalten und bei denen ausgerechnet an der schnellen Massenspeicheranbindung gespart wurde?

Vielleicht sind große lokale Server nicht tot. Aber ihr bisheriger Einsatzzweck gehört zunehmend hinterfragt. Die Frage ist nicht mehr, wie viel wir auf einen Host packen können, sondern wie wir mit möglichst wenig Overhead möglichst viel reale Leistung bekommen. Weniger Ballast, mehr Fokus. Weniger Nostalgie für alte Architekturprinzipien, mehr Mut zu schlanken, modernen Setups.

Manchmal ist der kleine, unscheinbare Mini-PC im Rack die deutlich ehrlichere Antwort als das nächste tonnenschwere „Enterprise“-Monster.

PDFs sind keine Digitalisierung

bbcode-image


Wir leben in einer Zeit, in der „alles digital“ sein soll. Papier gilt als Relikt vergangener Tage, und in vielen Unternehmen ist das erklärte Ziel, möglichst keine physischen Dokumente mehr zu produzieren. Gleichzeitig zeigt der Alltag, dass Papier noch erstaunlich oft zum Einsatz kommt. Doch selbst dort, wo Ordner verschwinden und Scanner surren, bedeutet das noch lange nicht, dass echte Digitalisierung stattfindet.

Denn wer seine Zettelwirtschaft einfach einscannt und als PDF ablegt, hat im Kern nur das Medium gewechselt. Der Prozess dahinter bleibt derselbe. Eine digitale Mitarbeiterakte ist eben nicht einfach ein Netzlaufwerk mit hunderten von eingescannten Dokumenten. Ein Produktkatalog, der als PDF verschickt oder auf die Website gestellt wird, ist kein digitaler Vertriebskanal, sondern lediglich ein gedrucktes Dokument in neuem Gewand. Das Ergebnis wirkt moderner, doch die Strukturen bleiben analog gedacht.

Wer durch kleine und mittelständische Unternehmen in Deutschland geht, gewinnt oft den Eindruck, dass die gesamte Organisation auf vier Grundpfeilern ruht: Windows, Word, Excel und Outlook. Diese Werkzeuge sind allgegenwärtig und zweifellos nützlich. Doch sie ersetzen keine durchdachten Systeme. Spezialisierte Lösungen wie PIM-, CRM- oder Warenwirtschaftssysteme sind deutlich seltener im Einsatz, als man es in einer angeblich digitalisierten Wirtschaft erwarten würde. Je größer und internationaler ein Unternehmen ist, desto eher findet man solche spezialisierten Softwarelösungen. Gerade kleinere Firmen hingegen begnügen sich häufig damit, Papier in Dateien zu verwandeln, ohne ihre Prozesse grundlegend zu hinterfragen oder anzupassen.

Besonders irritierend ist in diesem Zusammenhang, wie hartnäckig sich alte Denkweisen halten. Dass der Begriff „Fax“ im Jahr 2026 immer noch selbstverständlich fällt, wirkt fast surreal. Warum sollte man eine PDF-Datei faxen, wenn sie sich per E-Mail in Sekunden verschicken lässt? Solche Fragen zeigen, dass es oft nicht an der Technik fehlt, sondern am Verständnis für digitale Möglichkeiten und an der Bereitschaft, Gewohnheiten zu verändern.

Ein zentrales Problem ist dabei das mangelnde Bewusstsein für den Wert strukturierter Daten. Ein gescanntes Dokument ist im Grunde nur ein Bild. Es lässt sich nicht sinnvoll auswerten, automatisiert verarbeiten oder zuverlässig analysieren. Echte Digitalisierung bedeutet, Informationen so zu erfassen, dass sie durchsuchbar, verknüpfbar und auswertbar sind. Reports, Analysen und Auswertungen sollten nicht davon abhängen, dass ein Mitarbeiter stundenlang Daten manuell zusammensucht und in Excel-Tabellen kopiert. Moderne Systeme erledigen solche Aufgaben automatisiert und schaffen damit Freiräume für wertschöpfende Tätigkeiten.

Wer als Entwickler in ein solches Umfeld kommt, stellt schnell fest, dass die Rolle weit über das reine Programmieren hinausgeht. Man wird zum Berater, manchmal sogar zum Übersetzer zwischen alter und neuer Welt. Es geht nicht nur darum, Software einzuführen, sondern Mindsets zu verändern und Versäumnisse der letzten fünfzehn Jahre aufzuholen. Das ist oft ein kultureller Prozess, kein technischer.

Und nein, ein Unternehmen ist nicht automatisch modern, nur weil seine Excel-Datei in der Cloud liegt oder über OneDrive synchronisiert wird. Die Speicherung ändert nichts an der grundlegenden Logik, nach der gearbeitet wird. Digitalisierung bedeutet nicht, analoge Prozesse zu konservieren und ihnen einen digitalen Anstrich zu geben. Sie bedeutet, Prozesse neu zu denken, Daten strukturiert nutzbar zu machen und Technologie als strategisches Werkzeug zu verstehen. PDFs sind dabei höchstens ein Zwischenschritt – aber ganz sicher nicht das Ziel.

KI ohne messbaren Impact – oder nur falsch eingeführt?

bbcode-image


In den letzten Monaten war immer wieder zu lesen, dass Unternehmen trotz verfügbarer KI-Werkzeuge keine echte Steigerung ihrer Produktivität messen konnten. Führungskräfte berichten davon, dass man viel ausprobiert habe, Lizenzen eingekauft wurden und dennoch am Ende keine klaren Zahlen vorlägen, die einen Durchbruch belegen. Auffällig ist jedoch, dass selten darüber gesprochen wird, wie genau KI eingeführt wurde, welche Bereiche betroffen waren und welche Erwartungen man eigentlich an den Einsatz geknüpft hat.

KI ist kein Werkzeug wie Outlook, das man einfach jedem Mitarbeitenden zur Verfügung stellt, in der Hoffnung, es werde sich schon von selbst sinnvoll integrieren. Wer Unternehmen beobachtet, die gleichzeitig KI- und Cloud-Initiativen starten, erkennt schnell ein wiederkehrendes Muster. Technologie wird bereitgestellt, doch Prozesse, Verantwortlichkeiten und Denkweisen bleiben unverändert. Die Enttäuschung folgt dann meist planbar.

Nicht jeder Arbeitsbereich profitiert in gleichem Maße von KI. Wer täglich viele E-Mails schreibt, braucht oft keine komplexen Prompts, wenn das Formulieren des Prompts am Ende genauso lange dauert wie die Nachricht selbst. Zudem wiederholen sich Formulierungen häufig, sodass der Mehrwert begrenzt ist. Ganz anders sieht es in der Softwareentwicklung aus. Dort entstehen Prototypen nicht mehr erst nach zwei Tagen intensiver Arbeit, sondern entwickeln sich bereits während der Konzeptionsphase. Neue Features lassen sich schneller implementieren, wodurch deutlich mehr Zeit für Tests, Qualitätssicherung und echte Verbesserung bleibt. Der Effekt ist hier nicht nur eine Beschleunigung, sondern auch eine qualitative Verschiebung der Arbeit.

Entscheidend ist jedoch nicht allein das Werkzeug, sondern das Verständnis für seinen Einsatz. KI sinnvoll zu nutzen bedeutet nicht, fünf Standard-Prompts zu kennen und diese minimal anzupassen. Jede Aufgabe ist anders, jede Fragestellung hat ihren eigenen Kontext. Wer glaubt, zwei Entwickler könnten sich intensiv einarbeiten und anschließend zwanzig weiteren Kolleginnen und Kollegen in einer kurzen Schulung ein paar Prompts an die Hand geben, damit das gesamte Team „KI-enabled“ ist, unterschätzt die Tiefe des Themas. KI ist weniger eine Frage der Bedienung als eine Frage des Mindsets.

Gerade im klassischen Büroalltag zeigt sich diese Problematik besonders deutlich. KI verhält sich hier ähnlich wie Cloud-Technologie. Man kann nicht einfach OneDrive bereitstellen, einen Link mit der Überschrift „So funktioniert OneDrive“ verschicken und erwarten, dass plötzlich alle Prozesse cloudbasiert, effizient und strukturiert ablaufen. Technologie entfaltet ihren Nutzen nur dann, wenn Menschen verstehen, wie sie bestehende Arbeitsweisen anpassen müssen, um von den Vorteilen zu profitieren. Es geht darum, Arbeitsprozesse neu zu denken, statt alte Muster digital zu kopieren.

Warum bleibt der messbare Impact also häufig aus? Oft werden lediglich Werkzeuge bereitgestellt, ohne begleitende Strukturveränderung. Man verlässt sich darauf, dass Mitarbeitende schon selbst herausfinden werden, wie man KI sinnvoll einsetzt, ohne ihnen dafür Zeit oder Raum zum Experimentieren zu geben. Führungskräfte, die selbst wenig Berührungspunkte mit der Technologie haben, können zudem schwer beurteilen, ob sie richtig oder oberflächlich genutzt wird. Hinzu kommt, dass Produktivität in vielen Bereichen schon vor der Einführung von KI schwer messbar war. Backoffice-Abteilungen oder interne Softwareentwicklung generieren keinen unmittelbar sichtbaren Umsatz. Wer hier erwartet, einen Monat nach Einführung direkt messbare Gewinnsteigerungen zu sehen, setzt falsche Maßstäbe.

Eine ernsthafte Einführung von KI bedeutet deshalb, jeden Arbeitsplatz und jeden Prozess einzeln zu betrachten. Es geht darum zu analysieren, wo echte Hebel liegen, wie Verbesserungen bewertet werden können und welche Kennzahlen überhaupt sinnvoll sind. In vielen Bereichen führt KI bereits heute zu enormen Produktivitätssteigerungen oder zumindest zu einer Verschiebung von Tätigkeiten, sodass die Qualität der Ergebnisse deutlich steigt. Nicht jede Verbesserung zeigt sich sofort in Umsatzkennzahlen, manche äußert sich in geringerer Fehlerquote, höherer Innovationsgeschwindigkeit oder zufriedeneren Mitarbeitenden.

Wer behauptet, KI bringe keinen messbaren Impact, sollte sich daher zunächst selbstkritische Fragen stellen. Liegt es vielleicht am Aufgabenbereich, in dem der Nutzen naturgemäß geringer ist? Wurden Mitarbeitende wirklich geschult, eingebunden und befähigt, oder hat man ihnen lediglich ein neues Tool vor die Nase gesetzt? Und misst man womöglich falsch, weil man davon ausgeht, dass sich Verbesserung ausschließlich in kurzfristigen finanziellen Kennzahlen zeigen muss?

Einfach zu sagen, KI bringe nichts und man müsse sich deshalb nicht weiter damit beschäftigen, ist eine bequeme Haltung. Langfristig jedoch werden jene Unternehmen vorne liegen, die nicht nur Werkzeuge einführen, sondern Denkweisen verändern. Wer heute aus Frust oder Ungeduld aussteigt, könnte morgen feststellen, dass andere im selben Marktumfeld sehr wohl gelernt haben, das Potenzial zu heben. Dann war es nicht die Technologie, die keinen Impact hatte, sondern die eigene Ignoranz gegenüber dem notwendigen Wandel.

„Wenn du doch länger brauchst, sag bitte dann Bescheid …

bbcode-image


Diesen Satz habe ich in Projekten schon oft gehört. Und jedes Mal schwingt darin dasselbe mit: Unsicherheit. Unsicherheit darüber, wie lange etwas wirklich dauert, was es am Ende kosten wird und wer eigentlich das Risiko trägt.

Ich mochte Projektarbeit zu Festpreisen schon immer lieber als Time & Material. Und seit ich wieder in der internen Softwareentwicklung arbeite und regelmäßig mit Agenturen und externen Anbietern zu tun habe, fühle ich mich darin nur noch mehr bestätigt.

Ich brauche keine hochkomplexen Kalkulationen, um das Risiko eines Projekts zu bewerten. Ein Festpreis zwingt automatisch dazu, sich früh Gedanken zu machen: Was ist wirklich Teil des Projekts, was nicht, und wo liegen die Unsicherheiten? Gerade auf Kundenseite ist das ein enormer Vorteil. Freigaben zu bekommen ist viel einfacher, wenn nicht ständig die Frage im Raum steht, was passiert, wenn das Projekt fast fertig ist, aber doch noch mehr Geld benötigt wird – und ob es sich dann überhaupt noch lohnt, weiterzumachen.

Auch in der Rolle des Anbieters ziehe ich Festpreise klar vor. Ich weiß von Anfang an, was ich verdienen werde und wie lange ein Projekt maximal dauern darf. Dadurch lasse ich mich nicht auf Endlosprojekte ein, bei denen zwar kontinuierlich Geld fließt, aber kein Ende in Sicht ist. Nachverhandlungen entfallen ebenfalls, weil der finanzielle Rahmen klar ist und sich daran nichts mehr ändert.

Diese Klarheit hat einen wichtigen Nebeneffekt: Ich muss selbst sauber planen. Eigene Unzulänglichkeiten lassen sich nicht einfach auf den Kunden abwälzen, indem man sagt, dass alles eben länger dauert und deshalb mehr kostet. Gleichzeitig nimmt ein Festpreis dem Kunden sehr viel Unsicherheit. Selbst wenn etwas nicht ideal läuft, steigen die Kosten nicht plötzlich. Diese Sicherheit ist Kunden auch Geld wert. Viele zahlen lieber etwas mehr, als später intern erneut Prozesse durchlaufen zu müssen, um zusätzliches Budget freizugeben.

Natürlich hat Time & Material seine Berechtigung. In der Praxis verleitet dieses Modell jedoch schnell zu problematischem Verhalten. Häufig wird nicht ausreichend geplant oder spezifiziert, weil Vorleistungen nicht bezahlt werden und man möglichst schnell abrechenbare Stunden generieren möchte. Neue Anforderungen werden gerne noch in laufende Projekte aufgenommen, weil sie vielleicht noch ins geplante Budget passen könnten. In der Realität tun sie das nie. Beim Festpreis ist hingegen klar, dass zusätzliche Anforderungen extra kosten – und vor allem auch, wie viel genau.

Time & Material ermöglicht außerdem Preis-Dumping, weil kein Risiko eingepreist werden muss. Beim Festpreis werden sowohl der Initialaufwand als auch ein Puffer berücksichtigt. Bei Time & Material wird dagegen oft gehofft, diesen Initialaufwand über die Laufzeit des Projekts zu kompensieren. Wenn alles länger dauert, ist das erst einmal egal, denn der Kunde zahlt weiter – zumindest so lange, bis er sich weigert oder das Ganze juristisch eskaliert.

Ein weiterer Punkt, der mir beim Festpreis wichtig ist, betrifft die eigene Freiheit in der Zeitplanung. Dem Kunden ist es egal, wie lange ich tatsächlich brauche oder wann ich arbeite. Ich liefere ein Feature, keine Arbeitszeit. Natürlich kann auch ein Festpreisprojekt grob zeitlich eingeordnet werden, und das ist oft sinnvoll, damit der Kunde weiß, wann er womit rechnen kann. Der entscheidende Unterschied ist jedoch, dass der Druck nur auf der Auslieferung liegt und nicht darauf, möglichst wenig Zeit zu bezahlen.

Sollte etwas deutlich schneller gehen als gedacht, kann man immer noch einen Rabatt gewähren. Das freut den Kunden und stärkt die Beziehung. Die Kontrolle bleibt dabei trotzdem beim Anbieter, und der Kunde kann keinen Druck aufbauen in der Hoffnung, durch Verzögerungen weniger zahlen zu müssen.

Mein persönliches Fazit – gerade auch mit Blick auf neue Arbeitsweisen und KI – ist daher recht klar: Es geht um den Wert eines Features, nicht um die Zeit, die seine Umsetzung gebraucht hat. Wenn jemand eine sehr gute Idee hat und dadurch extrem schnell liefert, ist das oft mehr wert als eine Lösung, die länger braucht. Eigentlich sollte dann auch genau diese Leistung besser bezahlt werden.

Lass dir Schnelligkeit und Qualität bezahlen, nicht die Tatsache, dass du besonders lange an einem Feature arbeitest. Gib dem Kunden die Kontrolle über das Projekt zurück. Denn je geringer das Risiko ist, desto entspannter – und am Ende auch besser – arbeiten alle Beteiligten.

Vibe-Coding ist keine Demokratisierung

bbcode-image


In meiner LinkedIn-Bubble lese ich aktuell ständig von Menschen, die sich durch „Vibe-Coding“ in kürzester Zeit großartige Produkte gebaut haben – ganz ohne Programmierer.

Sie seien nun endlich selbst in der Lage, ihre Vorstellungen und Pläne in ein fertiges Produkt zu verwandeln. Kein Ticket schreiben. Kein Entwickler-Briefing. Kein Warten.

Das klingt nach Demokratisierung.
Ist es aber nicht.

Die Rolle des Programmierers war nie die, die man ihr gerade zuschreibt

Was mich an dieser Erzählung stört: Sie schiebt die Rolle des klassischen Programmierers in eine Höhe, die sie seit Jahren faktisch nicht mehr innehat.

Anfang der 2000er war Programmieren tatsächlich noch stark mit technischer Exzellenz verbunden. Man schrieb viel Code selbst, dachte intensiv über Strukturen und Speicher nach und arbeitete teilweise sogar noch direkt mit Pointern. Wer mit C oder gar Assembler gearbeitet hat, weiß, wie viel konzeptionelle und technische Denkleistung darin steckte. Damals bestand ein großer Teil der Arbeit darin, sich überhaupt zu überlegen, wie eine Idee technisch umsetzbar ist und wie sie sauber im Code abgebildet werden kann.

Ab etwa 2010 hat sich das grundlegend verändert. Frameworks und Libraries haben einen Großteil der Arbeit übernommen. Mit Maven, Composer oder npm zieht man sich heute nahezu alles ins Projekt, was man benötigt. Authentifizierung, UI-Komponenten, Datenbankzugriff oder komplette Backend-Strukturen lassen sich mit wenigen Befehlen integrieren. Die wirklich harte technische Komplexität ist in den meisten Anwendungsbereichen verschwunden oder zumindest stark abstrahiert worden.

Code schreiben ist heute keine Kunst mehr

Das meine ich nicht abwertend, sondern nüchtern. In den allermeisten modernen Softwareprojekten ist das eigentliche Schreiben von Code nicht mehr der kreative Kern der Arbeit. Es ist häufig Fleißarbeit.

Man hat den Plan im Kopf, kennt die Architektur und weiß genau, wie das System aufgebaut sein soll. Der schwierigste Teil – das Denken, Strukturieren und Entscheiden – ist bereits passiert. Danach folgt oft nur noch die relativ langwierige Überführung dieser Gedanken in Code. Natürlich geht das mit moderner Autovervollständigung deutlich schneller als früher. Trotzdem bleibt ein Gefühl: Man würde eigentlich gerne so schnell schreiben, wie man denken kann.

Genau hier setzt KI an. Sie tippt schneller. Aber sie ersetzt nicht das Denken.

Entwickler waren schon immer mehr als Code-Schreiber

Wer nie selbst programmiert hat, denkt oft, der Entwickler sei in erster Linie derjenige, der Code schreibt. In Wirklichkeit war das schon lange nicht mehr die entscheidende Rolle.

In vielen Teams sieht man das klassische Gefälle zwischen Senior und Junior. Der Senior entwickelt Konzepte, entscheidet über Architektur, priorisiert und entwirft Lösungen. Der Junior schreibt einen Großteil des Codes. Nicht, weil er die bessere Idee hatte, sondern weil das reine Runterschreiben von Code nicht die wertvollste Kompetenz im gesamten Prozess ist.

Wenn man es so betrachtet, ersetzt KI im Grunde genau diesen mechanischen Teil. Sie ist ein schnelleres Werkzeug, das die Umsetzung beschleunigt. Mehr nicht.

Demokratisierung? Nein.

Demokratisierung würde bedeuten, dass sich die Machtverhältnisse verschieben. Dass plötzlich Menschen Produkte entwickeln können, die es vorher nicht konnten.

Aber das stimmt so nicht.

Die Person, die ein Produkt wirklich durchdenken und entwickeln kann, konnte das auch schon vorher. Programmieren zu lernen ist heute kein exklusives Privileg mehr. Die Tools sind seit Jahren zugänglich, die Komplexität in vielen Bereichen stark reduziert und die Einstiegshürden vergleichsweise niedrig. Wer in der Lage ist, ein Produkt sauber zu konzipieren, wäre auch ohne KI in der Lage gewesen, es selbst zu programmieren. Es hätte nur mehr Zeit gekostet.

KI spart Zeit. Sie verschiebt keine Kompetenz.

Der eigentliche Engpass war nie das Programmieren

Meine Mutter wird kein Produkt per Vibe-Coding entwickeln. Nicht, weil am Ende kein Code generiert würde. Sondern weil sie bereits an der grundlegenden Entwicklung und am Konzept scheitern würde.

Der eigentliche Engpass liegt nicht im Schreiben von Code, sondern in der Fähigkeit, Probleme sauber zu analysieren, Anforderungen zu strukturieren, Prioritäten zu setzen, Features sinnvoll zu designen und ein echtes Verständnis für Nutzer und deren Bedürfnisse zu entwickeln. Genau dort entsteht der Wert. Genau dort entscheidet sich, ob ein Produkt funktioniert oder nicht.

Diese Kompetenzen waren schon immer entscheidend – lange bevor KI existierte.

Wer sollte hier eigentlich stolz sein?

Deshalb mein Punkt: Wer jetzt stolz ist, per Vibe-Coding ein Produkt gebaut zu haben, sollte Programmierer nicht größer machen, als sie sind, und sich selbst nicht kleiner, als man eigentlich ist.

Die Kompetenz lag nie primär im Tippen von Code. Sie liegt im Denken, im Strukturieren und im echten Produktverständnis.

KI macht den Prozess schneller. Aber sie demokratisiert ihn nicht.

Die Macht verschiebt sich nicht.
Nur das Werkzeug wird schneller.

Und vielleicht ist genau das die eigentliche Wahrheit hinter dem ganzen Hype.

Schnelles Kopieren einer Firebird-2.5-Datenbank unter Linux

bbcode-image


Wer mit großen Firebird-2.5-Datenbanken arbeitet, kennt das Problem:
Ein klassisches Backup mit gbak kann extrem lange dauern. In meinem Fall benötigte ein gbak-Backup einer ca. 90-GB-Datenbank auf einem Surface-PC über 12 Stunden.

Mit nbackup lässt sich das gleiche Ziel jedoch in rund 20 Minuten erreichen.

Der verwendete Befehl


cd /usr/local/firebird/bin && \
./nbackup -user SYSDBA -password masterkey -L /firebird/data/testdb.fdb && \
cp /firebird/data/testdb.fdb /firebird/data/testdb_bkp_$(date +%Y%m%d).fdb && \
./nbackup -user SYSDBA -password masterkey -N /firebird/data/testdb.fdb && \
./nbackup -user SYSDBA -password masterkey -F /firebird/data/testdb_bkp_$(date +%Y%m%d).fdb


Was passiert hier genau?

nbackup -L (Lock)
Die Datenbank wird kurzzeitig in einen konsistenten Zustand versetzt.
Schreibzugriffe werden blockiert, laufende Leser dürfen weiterarbeiten.

cp
Die Datenbankdatei wird direkt auf Dateisystem-Ebene kopiert.
Das ist extrem schnell, da keine logische Analyse der Daten erfolgt.

nbackup -N (Normal)
Die Datenbank wird wieder freigegeben und arbeitet ganz normal weiter.

nbackup -F (Fixup)
Die Kopie wird „repariert“, sodass sie als eigenständige, saubere Datenbank genutzt werden kann.

Warum ist das schneller als gbak?

gbak arbeitet logisch:

- jede Tabelle,
- jeder Index,
- jeder Datensatz
wird gelesen, interpretiert und neu geschrieben.

Das ist sicher und portabel, aber bei großen Datenmengen sehr langsam.

nbackup dagegen arbeitet physisch:

- es wird praktisch eine konsistente Momentaufnahme der Datenbankdatei erstellt,
- ohne Daten zu interpretieren oder neu aufzubauen.

Das Ergebnis:
➡️ Minuten statt Stunden bei sehr großen Datenbanken.

Fazit

Für schnelle Sicherungen oder Klone großer Firebird-2.5-Datenbanken ist nbackup die deutlich bessere Wahl.
gbak bleibt sinnvoll für Migrationen oder Versionswechsel – aber für den Alltag spart nbackup enorm viel Zeit und Nerven.

nbackup gibt es natürlich auch unter Windows!

Was wird in zwei Jahren sein?

bbcode-image


Was wird in zwei Jahren sein? Diese Frage beschäftigt mich in letzter Zeit immer häufiger. Es sind keine ausgearbeiteten Prognosen, sondern eher lose Überlegungen darüber, wie sich alles entwickeln könnte, wenn die aktuelle Dynamik anhält. Und falls es am Ende doch ganz anders kommt, dann lag ich eben daneben. Sollte sich jedoch herausstellen, dass ich mit meinen Einschätzungen richtig liege, werde ich vermutlich nicht widerstehen können, das mit einem gewissen Stolz zu erwähnen.

Wenn ich mir anschaue, mit welcher Geschwindigkeit ich in den letzten Tagen neue kleine Tools und Features in bestehende Legacy-Systeme eingebaut habe, wird mir deutlich, dass sich etwas Grundlegendes verändert hat. Aufgaben, die früher Planung, Abstimmung und viele Stunden konzentrierter Entwicklungsarbeit erfordert hätten, lassen sich heute oft in einem Bruchteil der Zeit umsetzen. Dieses Gefühl von Beschleunigung ist nicht mehr nur ein leises Hintergrundrauschen, sondern wird zunehmend zum dominanten Taktgeber im Arbeitsalltag.

Das Disruptive daran ist, dass diese Veränderung längst nicht mehr nur innerhalb der Softwareentwicklung zu spüren ist. Ich hatte zuletzt mehrere Anfragen dazu, wie sich etwa Plugins für Shop-Systeme mithilfe von KI entwickeln lassen. Gleichzeitig wächst das Unverständnis darüber, warum man noch mehrere Personentage bei einer Agentur einkaufen sollte, wenn sich vergleichbare Ergebnisse scheinbar in wenigen Stunden erzielen lassen. Diese Perspektive ist nachvollziehbar und wirft gleichzeitig spannende Fragen auf: Wie wird die Zusammenarbeit mit Agenturen künftig aussehen, wenn der eigentliche Code nicht mehr zwingend von ihnen stammt, sondern von einer KI generiert wird, die theoretisch von jedem bedient werden kann? Genau an diesem Punkt entscheidet sich, wie Agenturen in Zukunft ihren Wert definieren und ihr Geld verdienen werden.

Wird KI Jobs verändern? Daran besteht für mich kein Zweifel. Ich habe das Gefühl, mich gerade mitten im Epizentrum dieser Entwicklung zu befinden, weil die Softwareentwicklung vermutlich eines der ersten Berufsfelder ist, das die volle Härte, aber auch das enorme Potenzial dieser Technologie zu spüren bekommt. Einige Menschen werden ihren Job verlieren, wenn sie sich nicht anpassen, und selbst diejenigen, die sich weiterentwickeln, werden möglicherweise feststellen, dass künftig einfach weniger Entwickler benötigt werden.

Doch die Veränderungen gehen noch tiefer. Je besser KI wird, desto mehr verliert Software als Produkt an sich an Bedeutung. Ich ertappe mich immer häufiger dabei, dass ich nicht mehr gezielt nach Websites oder Tools suche, um kleine Aufgaben zu erledigen. Stattdessen lasse ich mir einfach eine kleine Web-App erstellen, die genau auf meinen Bedarf zugeschnitten ist. Wenn sich diese Entwicklung fortsetzt, könnte es sich irgendwann kaum noch lohnen, Standardsoftware zu kaufen, wenn man sie sich direkt individuell generieren lassen kann. Viele Anwendungen sind in ihrer Struktur einfacher, als sie auf den ersten Blick wirken, und genau hier spielt KI ihre Stärke aus.

Was also macht ein Entwickler in zwei Jahren? Ich vermute, dass sich die Rolle deutlich verschiebt. Entwickler werden stärker definieren, was Software leisten soll und wie Systeme miteinander interagieren müssen. Sie werden Code eher prüfen als selbst schreiben, Kontext zu bestehenden Legacy-Systemen dokumentieren und alte Strukturen so aufbereiten, dass KI effektiv damit arbeiten kann. Gleichzeitig werden sie Unternehmen dabei unterstützen, KI sinnvoll einzusetzen, Automatisierungen zu entwickeln und neue Arbeitsweisen zu etablieren. Das wichtigste Werkzeug eines Entwicklers wird dabei die KI selbst sein.

Für mich persönlich bedeutet das, dass ich aktuell vor allem in einem überschaubaren Zeithorizont plane. Die nächsten zwei Jahre erscheinen mir greifbar genug, um Entscheidungen über neue und bestehende Systeme sowie deren Weiterentwicklung und Pflege zu treffen. Ich gehe davon aus, dass KI in diesem Zeitraum ein Niveau erreicht, auf dem sich ein Großteil der benötigten Standardsoftware direkt generieren lässt. Sollte mir ein Legacy-System dann nicht mehr passen, könnte es realistischer werden, es einfach neu zu bauen, statt es mühsam weiterzuentwickeln.

Ich stelle mir Meetings vor, in denen Fachabteilungen und Entwickler gemeinsam Anforderungen formulieren, während im Hintergrund bereits neue Versionen der Software entstehen. Eine Art „Vibe-Coding“ im größeren Maßstab, bei dem Systeme kontinuierlich angepasst und neu zusammengesetzt werden. Mein persönlicher Vorteil liegt dabei weniger im eigentlichen Programmieren, sondern darin, dass ich die Firma, ihre Prozesse und ihre Sprache kenne. Diese Fähigkeit, Anforderungen klar und eindeutig zu formulieren, könnte wichtiger werden als jede einzelne Programmiersprache.

Am Ende bleibt dennoch eine große Unsicherheit. Es wird sich zeigen, ob diese Entwicklungen tatsächlich in der Geschwindigkeit eintreten, die heute möglich erscheint, und welche Auswirkungen sie auf Gesellschaft und Wirtschaft haben werden. Mein Eindruck ist, dass Deutschland auf viele dieser Veränderungen noch nicht ausreichend vorbereitet ist. Umso spannender wird es sein zu beobachten, wie sich Technologie, Arbeitswelt und Erwartungen in den kommenden Jahren gegenseitig beeinflussen und neu ausrichten.

Was verstehe ich unter einem Commitment?

bbcode-image


Der Begriff Commitment wird im Arbeitsalltag häufig verwendet, bleibt dabei aber oft unscharf. Für mich bedeutet ein Commitment deutlich mehr als ein loses „Ich kümmere mich darum“. Es ist eine bewusste Zusage und die Grundlage für professionelle Zusammenarbeit sowie für Vertrauen innerhalb eines Teams.

Ein Commitment beginnt damit, dass man klar kommuniziert, bis wann man sich um ein Thema gekümmert hat. Anschließend tut man alles dafür, diesen Zeitpunkt auch einzuhalten. Dabei geht es nicht darum, dass immer alles perfekt läuft. Entscheidend ist vielmehr, Verantwortung für die eigene Zusage zu übernehmen.

Es ist grundsätzlich kein Problem, wenn ein Commitment nicht eingehalten werden kann. Wichtig ist jedoch, dass die Gründe dafür nachvollziehbar sind und dass sie rechtzeitig und vollständig kommuniziert werden. Überraschungen kurz vor Ablauf oder gar erst auf Nachfrage untergraben Vertrauen und erschweren Zusammenarbeit unnötig.

Zu einem Commitment gehört für mich immer auch eine saubere und transparente Kommunikation. Dazu zählt, offen darzulegen, was konkret bereits umgesetzt wurde und welche Schritte unternommen wurden. Ebenso wichtig ist es, ehrlich zu benennen, welche Probleme aufgetreten sind und ob – und von wem – versucht wurde, Unterstützung zu bekommen. Gerade bei Schwierigkeiten ist es ein Zeichen von Professionalität, sich aktiv Hilfe zu suchen, statt Probleme still auszusitzen.

Wenn es Hindernisse gab, die sich nicht überwinden ließen, müssen auch diese klar benannt werden. Dabei geht es nicht um Rechtfertigung, sondern darum zu erklären, was genau nicht funktioniert hat und welche Auswirkungen das auf das Ergebnis oder den Zeitplan hat. Ebenso gehört zu guter Kommunikation die klare Aussage, ob ein Thema abgeschlossen ist oder wann realistisch mit einem Abschluss zu rechnen ist.

Ein weiterer wichtiger Aspekt ist die Reflexion. Treten Probleme auf, sollte man prüfen, ob sich daraus Verbesserungen für die eigenen Workflows oder für die bestehende Infrastruktur ableiten lassen. Ebenso relevant ist die Frage, ob man plant, diese Verbesserungen auch tatsächlich umzusetzen. Ein Commitment endet nicht zwangsläufig mit dem Ergebnis, sondern oft erst mit den daraus gezogenen Lehren.

Kommunikation ist dabei mindestens genauso wichtig wie die Umsetzung selbst. Eine gute Lösung, über die niemand Bescheid weiß oder deren Status unklar ist, bringt in der Praxis oft wenig. Umsetzung ohne Kommunikation führt fast zwangsläufig zu Missverständnissen, Doppelarbeit oder falschen Erwartungen.

Dabei darf man niemals davon ausgehen, dass die andere Seite ja hätte nachfragen müssen. Diese Annahme erzeugt unnötige Arbeit und verschiebt Verantwortung in die falsche Richtung. Die Pflicht zur Statuskommunikation liegt immer bei der Person, die das Commitment abgegeben hat – also beim aktiven Part.

Commitments sind deshalb kein formales Beiwerk, sondern eine absolute Voraussetzung für professionelle Arbeit. Ohne verlässliche Zusagen und transparente Kommunikation funktionieren weder Planung noch Zusammenarbeit, insbesondere nicht in Teams mit mehreren Abhängigkeiten.

Gleichzeitig ist es wichtig, Commitments nicht als Maßstab für den persönlichen Wert zu missverstehen. Wenn jemand es nicht schafft, Commitments zuverlässig einzuhalten, heißt das nicht automatisch, dass diese Person ein schlechter Entwickler oder eine schlechte Fachkraft ist. Es kann jedoch ein Hinweis darauf sein, dass Rollen mit hoher Verantwortung – etwa auf Senior-Level, in der Teamleitung oder in Führungspositionen – vielleicht nicht oder noch nicht der richtige nächste Schritt sind.

Commitment bedeutet am Ende klare Zusagen zu machen, aktiv zu kommunizieren, Verantwortung für Probleme und Verzögerungen zu übernehmen und aus Fehlern zu lernen. Wer das ernst nimmt, verbessert nicht nur die eigene Arbeit, sondern auch die Zusammenarbeit im gesamten Team.

Older posts:

Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?