Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

IT-Security

Produktentwicklung

Weitere Leistungen...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

WISSENS-HUB

Künstliche Intelligenz

Wenn KI Code schreibt: Wie viel Mensch braucht moderne Software noch?

Stefanie Hasler beleuchtet, wie Vibe Coding KI in die Softwareentwicklung integriert, ihre Grenzen zeigt und den Menschen unverzichtbar macht.

Vibe Coding: Wenn KI Code schreibt

<h2><strong>Digitalisierung — Was bedeutet das überhaupt?<br /> </strong></h2><p>Immer wieder treffen wir in unserem beruflichen Alltag als Berater auf Unternehmen, die „sich digitalisieren” wollen. Damit können ganz unterschiedliche Dinge gemeint sein: eine Transformation zur Arbeit in agilen Teams, eine Neuaufstellung der digitalen Infrastruktur, eine Umgestaltung der kompletten Unternehmenshierarchie bis zu einer Änderung des Geschäftsmodells.</p><p>Im für uns besten Fall ist unseren Auftraggebern im Vornherein das „Warum” und das „Was” klar, und es geht in unseren Gesprächen nur um das „Wie”. Hier handelt es sich um eine klassische Blaupause für Success Stories.<br /> Oft aber kommen wir in Grenzsituationen, in denen unseren Kunden zwar klar ist, dass sie sich ändern müssen — sei es bezüglich Prozessoptimierung, Wettbewerbsfähigkeit, Unternehmensgröße oder wegen <a href="https://www.prontoweb.org/5-gruende-ihr-unternehmen-zu-digitalisieren/">einer</a>  <a href="https://www.personalmanagement.info/hr-know-how/fachartikel/detail/7-gruende-zur-digitalisierung/">Vielzahl</a>  <a href="https://www.e-commerce-magazin.de/die-wichtigsten-gruende-die-unternehmen-zu-einer-digitalisierung-veranlassen">von</a>  <a href="https://www.computerwoche.de/a/warum-sich-deutsche-unternehmen-wandeln-muessen,3091084">anderen Gründen</a> , über die in anderen Blogs schon viel geschrieben wurde — aber nicht wie oder was. Meist kommt unser Mandat direkt aus der Führungsebene. Oft können wir den Unternehmen trotz aller Unklarheiten gut weiterhelfen. Manchmal aber auch nicht, wie die Erfahrung aus einem unserer letzten Projekte zeigt.</p><h2>Von B2B zu Marke</h2><p>Unser Kunde, der bisher im B2B-Bereich tätig war, wünschte sich eine teilweise Neuausrichtung. Das Portfolio sollte um eine Luxusmarke aufgestockt werden, welche explizite B2C-Orientierung mithilfe von Internet-Technologien vorsah. Unter Anderem sollten die Kunden der neuen Marke einen personalisierten Fragebogen ausfüllen, um ein perfekt auf sie zugeschnittenes Produkt zu erhalten. Im Vorfeld waren durch namhafte Startup-Berater Marktanalysen durchgeführt worden, man hatte sich auf einen Zielmarkt und eine grundsätzliche Strategie geeinigt. Ein erster Prototyp der neuen Website existierte ebenfalls bereits. Die Beratungsfirma empfahl uns als Partner für die weitere Umsetzung dieses Vorhabens. Berater von UX&I und codecentric machten sich euphorisch auf den Weg, einem neuen Produkt den Weg zu ebnen. Dabei wollten wir durch unsere Kompetenz im test- und hypothesengetriebenen Vorgehen sowie unseren hohen technischen Anspruch unserem Kunden einen Marktvorteil verschaffen.</p><p>Die Vertragsgestaltung sah ein agiles Vorgehen vor. Die Beauftragung war kurz: Sie umfasste nur den Umfang des Minimal Viable Products (MVP), eine Verlängerung war jedoch vorgesehen. — Schließlich wussten wir nicht, ob das Produkt Erfolg haben würde. Im Sinne eines Lean Startup trugen wir diese Entscheidung mit und hießen sie gut. Bereits nach kurzer Zeit stießen jedoch wir auf Herausforderungen, die wir nicht erwartet hatten.</p><h2>Neuland</h2><p>Es sollte eine Premium-Marke geschaffen werden, die über emotionalen Anspruch und hohe Produktqualität glänzen konnte. Da unser Kunde in diesem Feld bisher noch nicht tätig gewesen war, schlugen wir zwei Dinge vor:</p><ol><li>Einstellen eines Experten für Premium-Marken und deren Marketing sowie</li><li>Zahlen- und analysegetriebene Priorisierung der Gestaltung der Website als <a href="https://www.management-circle.de/blog/minimum-viable-products-mehrwerte/">MVP</a> . Hierbei ist die grundsätzliche Idee, mit einem kleinen Feature-Umfang zu beginnen, Hypothesen — zum Beispiel über das Kundenverhalten — aufzustellen und dann durch konkrete Experimente herauszufinden, welche dieser Hypothesen zutreffend sind und welche nicht. So stellt man sicher, dass man immer nah am tatsächlichen Kunden arbeitet und nicht Luftschlösser spezifiziert, die im schlimmsten Fall an den Kundenbedürfnissen vorbeigehen. Anschauliche Beispiele für diese Art des testgetriebenen Vorgehens sind <a href="https://medium.com/booking-writes/a-b-tests-and-copy-what-why-how-8cc4ae17eae2">booking.com</a>  oder <a href="https://medium.com/netflix-techblog/quasi-experimentation-at-netflix-566b57d2e362">Netflix</a> .</li></ol><p>Im konkreten Projekt stießen wir hier auf mehrere Widerstände: Ein Markenexperte wurde nicht eingestellt. Es gab einen Mitarbeiter<a href="#footnote"><sup>1</sup></a>  in der Marketing-Abteilung, der etwas über ein Drittel seiner Kapazität auf dieses neue Produkt legen sollte. Von ihm kam der meiste Input bezüglich strategischer Ausrichtung.<br /> A/B-Testing oder Verproben von Hypothesen an IT-Produkten waren im Konzern nicht verbreitet. Es gelang uns leider nicht, unsere Vorstellungen von testgetriebenem Vorgehen einzubringen. In den folgenden Monaten kam es daher oft zu Konflikten zwischen unseren Kollegen und Mitarbeitern auf Kundenseite.<br /> Sieht man sich das Umfeld an, in dem sich unser Kunde befand, ist das nur verständlich. Der Konzern war streng hierarchisch ausgelegt. Für jede Produktlinie mussten im Vorfeld Projektionen bezüglich des Verkaufs getroffen werden, für deren Einhaltung die Verantwortlichen geradestehen mussten. Testgetriebenes Vorgehen bedeutet auch immer, Scheitern in Kauf zu nehmen, falls sich die eigenen Hypothesen als falsch herausstellen. Zu sagen: „Wir lagen falsch”, ist in einem streng hierarchischen Großunternehmen oft ein schneller Weg zum Abstellgleis, zumindest aber ein politischer Risikofaktor.<br /> Hinzu kommt noch, dass man gerade im B2B-Umfeld häufig klare Metriken hat, die nichts mit vergleichsweise weichen Zahlen, wie Besucherzahlen einer Website oder Anzahl an Klicks, zu tun haben. – Eine neue Produktlinie verkauft sich oder verkauft sich nicht. Und da man Produktionszyklen mit einberechnet, ist auch der zeitliche Rahmen zwischen Konzeption und Verkaufsstart normalerweise ein anderer als der zeitliche Rahmen, den man benötigt, um evidenzbasiert eine Website zu entwickeln.</p><p>Dazu kam — rückwirkend betrachtet —, dass jeder Projektbeteiligte, sowohl im Team als auch seitens der Stakeholder, andere, zum Teil implizite Erfolgsmetriken im Kopf hatte, aus denen sich unterschiedliche Priorisierungen ergaben.</p><h3><strong>Learning:</strong></h3><p>Hier hätten wir als Berater die Bedürfnisse des Kunden besser erkennen und mehr auf seine Ängste, Wünsche und Vorstellungen eingehen können. Wir versuchten, dem Kunden eine Fehlerkultur abzufordern, die so nicht gelebt werden konnte, und stießen bei jedem Schritt auf natürliche Widerstände. Einen Schritt zurückzutreten und kritisches Beäugen des Projekts hätte allen Seiten gut getan.</p><h3>Agiles Arbeiten im nicht-agilen Umfeld</h3><p>Unsere Arbeitsweise als Berater in einem Unternehmen — unsere Kernkompetenz — ist Technik. Begleiten wir einen Kunden bei einer digitalen Neuausrichtung, tun wir das, indem wir in einem cross-funktionalen Team aus Entwicklern und Beratern in Zusammenarbeit mit Kundenmitarbeitern eine technische Lösung entwickeln. Normalerweise gehen wir gerade bei Unternehmen, für die agiles Arbeiten neu ist, nach <a href="http://scrum.org" target="_blank">Scrum</a>  vor. Der Product Owner (PO) und idealerweise einige Entwickler kommen in der Regel vom Kunden. Wir ergänzen durch weitere Entwickler und gegebenenfalls einen agilen Coach oder Scrum Master. Dass ein PO vom Kunden gestellt wird, ist unerlässlich. Akzeptanz im Unternehmen, Vernetzung, strategische Ausrichtung und nicht zuletzt die Priorisierung der für das Projekt notwendigen Arbeiten sollten vom Kunden kommen.</p><p>Im konkreten Beispielprojekt war vorgesehen, dass vom Kunden ein PO gestellt wird. Dieser war zuständig für die Priorisierung der Entwicklungstasks der Website sowie das Stakeholder-Management zwischen Marketing, Führungsebene und IT. Außerdem war von codecentric-Seiten ein agiler Coach eingeplant.<br /> Bereits im ersten Projektmeeting kam es zu Spannungen zwischen unserem agilen Coach und dem Kunden. Als Konsequenz wurde vereinbart, dass dieser agile Coach nicht mehr im Projekt tätig sein würde. In der allgemeinen Aufbruchstimmung, die sehr positiv aufgeladen war, einigten wir uns darauf, zunächst kein agiles Coaching zu benötigen.</p><h3><strong>Learning</strong>:</h3><p>Kommt es zu Spannungen zwischen agilem Coach und Kunden oder gar wegen agiler Vorgehensweise, kann das ein Indiz für starke kulturelle Differenzen sein. Hier ist es unabdingbar, das Projektsetting zu hinterfragen und neu zu justieren.</p><h3>Die Rolle des Product Owners</h3><p>Der uns zur Verfügung stehende Product Owner hatte einen beeindruckenden Hintergrund im klassischen Projektmanagement, unter Anderem im Leiten von Großprojekten mit mehreren hundert Beteiligten. Er stand dem Team nur anteilig zur Verfügung. Der Rest seiner Zeit war für andere Aufgaben eingeplant. Das führte zu einem klassischen Bottleneck: User Stories wurden nur unzureichend definiert, wiederholtes Nachfragen kostete viel Zeit und führte zu Frustrationen auf beiden Seiten. Zusätzlich waren die Rollenbilder in den Köpfen der Beteiligten unterschiedlich: Der Kunde sah unseren PO eher als klassischen Projektmanager, unser PO sah sich ebenfalls so. Wir hingegen versuchten, unsere Vorstellung eines POs auf den Kunden zu übertragen. Hier gelang es uns nicht, dieselbe Sprache zu sprechen wie unser Kunde.</p><p>Ein Teammitglied übernahm de facto die Rolle eines Proxy-POs, klärte Lücken in den User Stories ab und brachte fehlende Details in Erfahrung. Dies war in der vertraglichen Struktur nicht vorgesehen und wurde nie explizit abgeklärt. Als der entsprechende Kollege das Projekt verließ, wurde allen Verbleibenden eine schmerzliche Lücke bewusst, die vorher niemand wahrgenommen hatte.</p><h3><strong>Learning</strong>:</h3><p>Kann ein Kunde keinen oder keinen Vollzeit-PO stellen, benötigt man einen Proxy-PO oder — weicher formuliert — “Projektkümmerer”, der den Kundenmitarbeitern unter Anderem praktische PO-Aufgaben abnimmt. Weitere Teile dieser Rolle: Sprachrohr zum Kunden, Anlaufstelle für klärungsbedürftige Fragen etc.</p><p>Dies ist immer kundenspezifisch, in jedem Projekt unterschiedlich und sollte, wenn vorhanden, bereits in der Ausgestaltung des Vertrages festgehalten werden.</p><h3>Mangelnde interne Akzeptanz und Druck auf interne Mitarbeiter</h3><p>Das Projekt wurde von Anfang an mit hohem Druck vorangetrieben. Es gab Deadlines, die unter Anderem an Produktionszyklen gekoppelt waren. Gleichzeitig wechselten die Anforderungen an die Website stets, die Priorisierung der User Stories wirkte zuweilen chaotisch. Unsere Ansprechpartner beim Kunden waren über längere Zeiträume schwer erreichbar.</p><p>Hinterher stellte sich heraus, dass gerade dieses Projekt intern im Unternehmen keine hohe Akzeptanz genoss. Unsere Stakeholder waren oft auf dem Prüfstand und mussten in der begrenzten Zeit, die sie hatten, mehrere Projekte durchführen, von denen unseres nicht besonders hoch priorisiert war. Das führte zu einem Teufelskreis aus Kontextwechseln, Spannungen und Druck, der weitergegeben wurde.</p><p>Ein Beispiel kann der IT-Leiter sein, der zwar als Stakeholder an regelmäßigen Reviews teilnahm, aber nur um eine Beschwerdeliste ans Team weiterzugeben, was denn alles nicht funktioniere. Aus seiner Sicht ein vollkommen berechtigtes Vorgehen: Der Dienstleister muss Qualität liefern, und zwar genau wie spezifiziert. Wir erwarteten von unserem Kunden an dieser Stelle eine Flexibilität, die dieser nicht aufbringen konnte — sich ändernde Prioritäten und Anforderungen sind in einem Umfeld mit hohem Druck auf alle Beteiligten, bei klassischem Reporting, nicht vorgesehen.</p><h3><strong>Learning</strong>:</h3><p>Agilität braucht Freiraum. Entscheidet man sich für ein digitales Transformationsprojekt mit einem agilen Team, muss man diesem Team, inklusive Stakeholdern, die Freiheit geben, die es braucht. Hier ist Support oder entsprechende Akzeptanz auf allen Hierarchieebenen im Unternehmen notwendig.</p><h3>Projektende</h3><p>Das MVP „Website” kam zum Go-Live. Im weitergehenden Betrieb kam es dann zu personellen Wechseln in unserem Team: Der de facto Proxy-PO verließ das Team, neue Kollegen wurden eingearbeitet. Hier entstand eine Lücke, die niemand kommen sah. Gleichzeitig gab es jetzt Verkaufszahlen, die darauf hindeuteten, dass das Produkt, so wie es konzipiert war, am Markt — zumindest kurzfristig — keinen großen Erfolg hatte.<br /> Dementsprechend nahm der Druck zu, und es kam immer öfter zu Konflikten zwischen unseren Kollegen und Kundenmitarbeitern. Auch weil die Erwartungshaltungen nicht übereinstimmten und nicht explizit waren. Wir beschlossen schlussendlich gemeinsam, die weitere Kooperation bis auf Wartung der IT-Infrastruktur, die großteilig automatisiert abläuft, zu beenden.</p><h3><strong>Learning:</strong></h3><p>Wenn die jeweiligen Kulturunterschiede zu groß sind, um überbrückt zu werden, kann es sinnvoll sein, die Kooperation zu beenden. Das muss nichts Schlechtes sein: Beide Seiten haben Neues gelernt, Schritte gemeinsam unternommen. Das anfangs wenig greifbare Digitalisierungsvorhaben ist weiter konkretisiert worden. Mit dem Gelernten kann unser Kunde in zukünftigen Projekten schneller zu einem Erfolg kommen.</p><h3>Lessons Learned</h3><p>Wie genau Digitalisierung in schwierigen Umfeldern zu handhaben ist, ist von Fall zu Fall unterschiedlich. Die Begleitung eines Kunden ist so vielfältig wie unsere Kunden selbst. Klar ist: Viele Kunden haben ein echtes Anliegen, sich weiter in ein agiles Umfeld zu bewegen, dem Strom der Digitalisierung zu folgen, selbst wenn die gewachsenen, hierarchischen Strukturen nicht darauf ausgelegt sind. Als Projektpartner sehen wir es als unsere Aufgabe, unsere Kunden so gut wie möglich auf diesem Weg zu begleiten. Als agiles Unternehmen wissen wir, dass man am besten durch Fehler und den offenen Umgang damit lernt. Die zentralen/die wichtigstenErkenntnisse aus diesem Projekt sind:</p><h3>Digitalisierungsvorhaben benötigen Support und Freiraum</h3><p>Wer sein Unternehmen in die digitale Zukunft führen will, sollte sich im Klaren darüber sein, dass es sich unter Umständen um tiefgreifende Änderungen an einem gewachsenen System handelt. Diese Änderungen können nur erfolgen, wenn der erforderliche Support im Unternehmen da ist —von der Führungsebene aus durch alle Hierarchiestufen bis zum Team. Gleichzeitig benötigt das umsetzende Team den nötigen Freiraum, um sich entfalten und produktiv liefern zu können. Das beinhaltet oft einen kulturellen Wandel, den man bewusst vollziehen muss. Kultureller Wandel ist immer mit Spannungen und Schmerzen verbunden. Auch wir als Berater müssen lernen, diese Spannungen rechtzeitig zu erkennen und auf der geeigneten Ebene zu adressieren.</p><h3>Agilität ist nicht immer und für alle das Maß aller Dinge</h3><p>Berät man viel im agilen Umfeld, fällt es schwer, sich vorzustellen, wie irgendein anderes Vorgehen zum Erfolg führen kann. Gerade das Wasserfallmodell wird oft angeprangert. Oft zu Recht, jedoch: Gerade in großen Unternehmen gibt es auf allen Ebenen viele Menschen, die noch nie in Berührung mit agilem Vorgehen gekommen sind. Die berechtigte Sorgen haben, „ob das denn alles so funktioniert”. Hier gilt es, Vertrauen aufzubauen und behutsam vorzugehen, Kunden abzuholen und im Zweifelsfall auch einzugestehen, dass eine agile Transformation des Unternehmens zum gegebenen Zeitpunkt nicht oder nur teilweise erfolgen kann. Hier muss man differenziert vorgehen: Sei es, dass man einen „Projektkümmerer” ins Projekt aufnimmt, sei es, dass man dem Kunden ein anderes Unternehmen empfiehlt, das näher an der gewünschten Arbeitsweise des Kunden ist: Im Vordergrund darf nicht nur das „Aber Sie müssen doch jetzt alles anders machen” stehen. Auch kleine Anpassungen oder Veränderungen beim Kunden können mittel- und langfristig große Auswirkungen haben.</p><h3>Eine gemeinsame Sprache sprechen</h3><p>Zwischen Agilisten, DevOps-Mentalität, hierarchischen Großunternehmen und Startupkultur bestehen fundamentale Unterschiede in der Weltsicht. Zum Teil werden die gleichen Begriffe verwendet, jedoch in radikal unterschiedlichen Bedeutungen. Das kann dazu führen, dass man aneinander vorbei redet, ohne sich dessen bewusst zu sein. Eine Beauftragung für drei Monate kann für den einen ein Werkvertrag mit klaren Zielen, für den anderen ein „Time and Material” mit Vorschlägen sein. Hier ist es unabdingbar, dass man sich selbst und die Zusammenarbeit immer wieder kritisch hinterfragt und gerade bei Konflikten darauf achtet, wer sich wie ausdrückt und was genau gemeint ist. Nur so kann eine echte gemeinsame Lösung entstehen.</p><h2>Fazit</h2><p><span></span></p><p>Es ist schwer, ein Digitalisierungsvorhaben durchzuführen. Selbst wenn das „Was”, „Wie” und „Warum” von Anfang an klar sind, bestehen Ungewissheiten. Und diese Klarheit in allen Punkten entsteht nicht von alleine, sondern ist harte Arbeit. Wichtig ist, dass man sich immer wieder vor Augen führt, dass auch bei unklarer Sachlage ein Mehrwert entstehen und man aus einem Digitalisierungsvorhaben immer etwas lernen kann. Im Beispielprojekt hatte unser Kunde echten Mehrwert — zumindest ein Produkt und eine Website dafür. Beide Seiten gewannen wertvolle Einblicke: Der Kunde in die neue digitale Welt, wir in ein für das Team neues Setting zur Produktentwicklung. Alle Beteiligten können nun mit zukünftigen Herausforderungen besser umgehen. Digitalisierungsprojekte in Grenzsituationen können also durchaus für beide Seiten ein Erfolg sein, sogar wenn das übergeordnete Vorhaben im ersten Anlauf scheitern sollte.</p><p><a href="#fn-back"><sup>1</sup></a>  Wir entscheiden uns an dieser Stelle bewusst für das generische Maskulinum, um die Anonymität aller betroffenen Personen zu wahren.</p>

Kulturkampf Digitalisierung — eine Un-Success Story

<p><b>Software zu entwickeln bedeutet, Mehrwert für den Kunden zu schaffen. Zu oft wird hierbei der menschliche Faktor im System missachtet. Stefanie Hasler, Senior Fullstack Developerin bei codecentric, gibt einen kleinen Einblick auf ihre Sicht der Dinge – von qualitativer Softwareentwicklung über Work-Life-Balance bis hin zur unverzichtbaren Kaffeeküche. </b></p><p><strong><b>Niemand möchte sinnlose oder undurchdachte Software entwickeln. Stefanie, wie gelingt es dir, Mehrwert bei deiner Arbeit zu generieren?</b></strong></p><p><span>Schon der Begriff „sinnlose” Software wirft Fragen auf: Was für einen Zweck soll die Software erfüllen? Wer stellt die Anforderungen? Wessen Bedürfnisse erfüllt die Software? Ist zum Beispiel ein Videospiel wie „Bejeweled” sinnlos, da es die Menschheit nicht voranbringt? Wie sieht es mit einem Middle Layer in einer Enterprise-Architektur aus, das lediglich Daten von einem Format in das andere transformiert?</span><span> </span></p><p><span>Echten Mehrwert zu stiften, ist mir in einem Projekt sehr wichtig. Wenn ich nicht verstehe, welchen Zweck eine technische Umsetzung erfüllt, nerve ich meine Stakeholder so lange, bis ich zumindest verstanden habe, was sie wollen. Halte ich das nicht für sinnvoll, versuche ich sie zu überzeugen, oder rede mit der Person, die das Projekt aus der Sales-Perspektive betreut. Dabei kann sich dann herausstellen, dass ich etwas übersehen habe. Oder aber, dass die Strategie des Kunden nicht zielführend ist und nur Geld verbrannt wird. </span></p><p><span>Der andere Aspekt der Frage ist, was ich persönlich tun kann, wenn ich Software entwickle. </span><span>Undurchdachte Software schreibt jede*r Entwickler*in. Das liegt zum Teil in der Natur der Sache. </span><span>In den allerwenigsten agilen Projekten ist von Anfang an klar, was der finale Scope ist. Es kommt zu Richtungsänderungen und Umplanungen. Wichtig hierbei ist durchdachtes Vorgehen: Die Software sollte zu jedem Zeitpunkt auf einem Stand sein, der sowohl den eigenen Qualitätskriterien, als auch denen des Kunden entspricht. Das bedeutet aber auch, nicht viel zu weit im Vorfeld zu planen. „YAGNI (You ain’t gonna need it)” ist immer noch einer meiner häufigsten Sätze in Planungs-Meetings. </span></p><p><strong><b>Manche glauben, dass man im Consulting nie zu Hause ist – Wie bringst du hier dein Berufs- und Privatleben unter einen Hut?</b></strong></p><p><span>Eigentlich habe ich immer Kunden, die auch ein Privatleben haben und Freitag nachmittags nach Hause gehen und dort bleiben. Das ist vor allem unserem hervorragenden Sales-Team geschuldet, die schon im PreSales-Bereich dafür sorgen, dass wir auf Augenhöhe agieren können. </span><span>Klar gibt es immer mal wieder Projekte mit hektischen Phasen. Wieviel ich mich da einbringe, war jedoch bisher immer meine eigene Entscheidung und kein Kunde hat je von mir verlangt, dass ich mich verbiege. In den allermeisten Fällen hilft das der Produktivität sowieso nicht weiter und die Kunden, mit denen ich bisher interagieren durfte, verstehen das. </span></p><p><strong><b>Als Senior Fullstack Developerin bist du Vollprofi und hast bereits einige Jahre an Erfahrung. Wie schaffst du es, dein Fachwissen immer noch zu vertiefen, ohne dafür Freizeit zu opfern?</b></strong></p><p><span>Bisher ist mir in diesem Beruf noch kein Vollprofi begegnet. Aber zum Rest der Frage: Ich habe die Erfahrung gemacht, dass Wissen, das ich nicht anwenden kann, nicht lange in meinem Hirn bleibt. Ich bilde mich also in den Technologien fort, die ich sowieso schon im Projekt aktuell nutze. Bei jedem Kundeneinsatz lerne ich dazu. Zum Glück wird von unserem Sales-Team darauf geachtet, dass gemeinsames Lernen ein Teil des Projektes ist.</span><span> </span></p><p><span>Außerdem ist mir persönlich Work-Life-Balance sehr wichtig. Wenn ich 40 Stunden pro Woche Technik mache, dann muss diese Zeit ausreichen, um auch genug dazuzulernen, dass ich mich in der Öffentlichkeit schamlos als „Senior Fullstack Developer” präsentieren kann. </span><span>Dass ich bei codecentric Zeit bekomme, die ich in Fortbildung investieren kann, hilft natürlich ungemein. Diese Zeit nutze ich meist zur Vernetzung mit anderen Entwickler*innen, weil das meiner Lernstrategie am ehesten entspricht. </span></p><p><strong><b>Wie stark bist du persönlich von der Corona-Pandemie betroffen gewesen und wie ist dein Arbeitgeber damit umgegangen? </b></strong></p><p><span>„Teilhabe am öffentlichen Leben” hatte ich aufgrund eines Kleinkindes im Haushalt sowieso nicht mehr. Der Unterschied zwischen Pandemie und nicht-Pandemie ist für mich also, dass ich das Haus beruflich auch nicht mehr verlasse. </span><span>Von codecentric hieß es: „Bleibt zuhause, wenn Ihr Euch unsicher fühlt. Psychologische Unsicherheit zählt auch.” Deswegen war mein gesamtes Team seit Beginn der Pandemie im Homeoffice. Nachdem ich schon Remote-Erfahrung hatte, konnte ich dem Kunden helfen, ein Gerüst zur Vernetzung der Entwickler*innen in meinem Projekt aufzubauen, sodass wir uns gegenseitig gut unterstützen können. </span><span>Wir haben im codecentric-Büro in München auch Luftfilter, die dafür sorgen, dass wir dort sicher arbeiten können, wenn wir wollen. Die habe ich aber wegen Pendelei und Kita-Schließung noch nicht selbst testen können. </span></p><p><strong><b><b>Welche aktuellen Branchen-Entwicklungen siehst du kritisch?</b></b></strong></p><p><span>Aktuell geht es sehr oft darum, möglichst schnell etwas zu entwickeln. Was dabei oft hinten runter fällt, ist die Analyse der eigentlichen Probleme. Viele Kunden kommen zu uns mit einem groben Verständnis einer Lösung, die nicht unbedingt zu ihren Herausforderungen passt. </span><span>Manchmal habe ich den Eindruck, dass wir vorhandene Probleme mit – je nach Ausprägung – Bitcoin, KI, oder Cloud-Technologien bewerfen wollen, bis sie verschwinden, obwohl die Ursache an ganz anderer Stelle liegt. Klar bringt „mal eben schnell was machen” oft einen Wettbewerbsvorteil, die Frage ist aber, ob man sich überhaupt im richtigen Wettbewerb befindet.</span></p><p><span>Es gibt noch eine andere Sache, die mich wahnsinnig aufregt. Die ist zwar kein Trend im eigentlichen Sinne, hält sich aber leider hartnäckig. Wir reden alle zu wenig miteinander. Zum Teil ist das der Pandemie geschuldet; die Kaffeeküche ist ein integraler Bestandteil des Softwareentwicklungsprozesses. Aber auch sonst versuchen wir oft, immer mehr Schwierigkeiten auf der technologischen Ebene zu lösen als auf der zwischenmenschlichen. </span><span>Technologien lösen meiner Meinung nach keine Probleme. Menschen lösen Probleme mithilfe von Technologien. Das sollte immer im Vordergrund stehen. </span></p><p><strong><b>Zu guter Letzt, was würdest du Entwickler*innen, die aktuell unzufrieden in ihrer beruflichen Situation sind, ans Herz legen? </b></strong></p><p><span>Am wichtigsten ist es, einen Job zu finden, der zur eigenen Persönlichkeit passt. Meine persönliche Faustregel: Wenn man sich für ein Interview Kleidung anzieht, die man nicht anziehen will und über Dinge redet, die nichts mit den eigenen Interessen zu tun haben, bekommt man einen Job, mit dem man nicht glücklich wird.</span></p><p><span>Ich schlage vor, eine Liste mit Faktoren zu erstellen, die bei der Arbeit am wichtigsten sind. Ein paar Anregungen: Will ich, dass meine Arbeit Wert stiftet? Will ich gut bezahlt werden? Ist mir meine Freizeit wichtig? Will ich etwas Gutes für die Umwelt tun? Will ich soziale Gerechtigkeit? Wie wichtig ist mein Umfeld? </span><span>Wenn eine priorisierte Liste vorliegt, kann man viel leichter herausfinden, was einen unzufrieden macht. Und dann kann man daran arbeiten, genau diese Dinge zu ändern. Das kann einen Arbeitgeberwechsel beinhalten. Das kann aber auch sein, dass man sich in seiner Firma mehr vernetzt oder versucht, Veränderung in der Organisation zu bewirken. </span></p><p><span>Am Ende ist jeder <a href="https://www.codecentric.de/karriere" target="_blank">Job</a>  von Kompromissen geprägt, die man zwischen Work-Life-Balance, dem Gewissen, dem Umfeld und dem Geldbeutel schließt. Die Entscheidung, wo man Kompromisse eingeht und wo nicht, muss bewusst getroffen werden. </span><span>Ansonsten ist man nur im nächsten unpassenden Job.</span></p><p><strong><strong>Vielen Dank für das Gespräch, Stefanie.</strong></strong></p><p> </p><p> </p>

Technologien lösen keine Probleme ― es sind die Menschen dahinter

<h2>Introduction</h2><p>There are days when I find a piece of code I simply have to refactor. Sometimes because I actually have to for project-related reasons, sometimes because it’s easy to, and sometimes because I just want to. One definition of a nice day is when all these reasons meet.</p><p>Enter the Portuguese tax number verification.</p><p>For those who don’t know, in most countries the tax number has one or more check digits which are calculated according to some algorithm the country’s legislators think is up for the task. If you have a frontend where customers enter tax numbers, it’s a good first step to actually check the validity of the number according to the check digit in order to provide fast feedback to the user.</p><p>Usually I don’t do the research on the algorithms we implement for this myself. Someone else on my team calls someone from the country in the same organization and we code monkeys usually get code snippets, such as <a href="https://gist.github.com/eresende/88562d2c4dc85b62cb0c">this one</a> . In this case I got curious. The <a href="https://pt.wikipedia.org/wiki/N%C3%BAmero_de_identifica%C3%A7%C3%A3o_fiscal">portuguese wiki</a>  contains a nice explanation of the check digit algorithm, which is a variation of an algorithm called (according to google) the modulus 11 check digit algorithm.</p><ul><li>Implementing this from scratch probably would have been straightforward, but I decided to refactor for several reasons:<br /> Sometimes web sources can be wrong. Take, for example, <a href="https://wiki.scn.sap.com/wiki/display/CRM/Portugal">this community wiki</a> : Here they seem to have forgotten about a part of the algorithm. If this had been my first source, I’d have had a bug report. Thus I usually try to stay near the scripts my customers provide me with.</li><li>Refactoring this very isolated piece of code would be easy.</li><li>Sometimes the scripts we get from our colleagues contain a little bit of extra logic which make sense in the context where we use them. In this one, for example, I was told to “just don’t worry about the extra cases at the beginning. We are not interested in these and it’s okay to delete them.”</li></ul><p><em>Side note: </em>For the purposes of this exercise, I used ES6 transpiled with Babel. For my tests, I use mocha and chai.</p><p>Enough introduction! Let’s have a look at:</p><h2>The Code</h2><p>I admit I did a tiny bit of untested refactoring first: Returning true or false instead of an alert, exporting the function and deleting the, as per our definition unnecessary, lines.</p><div>

```javascript
export function validaContribuinte(contribuinte) {
// algoritmo de validação do NIF de acordo com
// http://pt.wikipedia.org/wiki/N%C3%BAmero_de_identifica%C3%A7%C3%A3o_fiscal
    let comparador;
    var temErro = 0;
 
    var check1 = contribuinte.substr(0, 1) * 9;
    var check2 = contribuinte.substr(1, 1) * 8;
    var check3 = contribuinte.substr(2, 1) * 7;
    var check4 = contribuinte.substr(3, 1) * 6;
    var check5 = contribuinte.substr(4, 1) * 5;
    var check6 = contribuinte.substr(5, 1) * 4;
    var check7 = contribuinte.substr(6, 1) * 3;
    var check8 = contribuinte.substr(7, 1) * 2;
 
    var total = check1 + check2 + check3 + check4 + check5 + check6 + check7 + check8;
    var divisao = total / 11;
    var modulo11 = total - parseInt(divisao) * 11;
    if (modulo11 == 1 || modulo11 == 0) {
        comparador = 0;
    } // excepção
    else {
        comparador = 11 - modulo11;
    }
 
    var ultimoDigito = contribuinte.substr(8, 1) * 1;
    if (ultimoDigito != comparador) {
        temErro = 1;
    }
 
    if (temErro == 1) {
        return false;
    }
    return true;
}
```

</div><h2>Where to start</h2><p>The first thing you want to do when you refactor code is have unit tests for the code. Since most code to refactor is hard to understand, a lot of people prefer to not even try and rather create a Golden Master test. A detailed explanation as well as a walkthrough in Java can be found <a href="http://craftedsw.blogspot.de/2012/11/testing-legacy-code-with-golden-master.html">here</a> .</p><h2>Creating a Golden Master</h2><p>So the <strong>steps to creating a Golden Master test</strong> are:</p><ol><li> Create a number of random inputs for your testee</li><li>Use these inputs to generate a number of outputs</li><li>Record the inputs and outputs.</li></ol><p>Why are we doing this?</p><p>If the number of random inputs is high enough, it’s very probable that we have all test cases in there somewhere. If we capture the state of the testee before we start changing anything, we can be sure we won’t break anything later.</p><p>There’s one thing I want to say now: <strong>A Golden Master record should in most cases be only a temporary solution</strong>. You do not really want files or databases full of randomly generated crap to clog your server, and you don’t want long-running tests with way too many redundant test cases on your CI server.</p><h4>Step 1: Create A Number Of Random Inputs</h4><p>For this, we have to actually look at the code to be refactored. A quick glance says: “This function takes strings of length 9 which contain only digits as valid input”.</p><p>My first instinct was to try and calculate all of them. After a few frustrating minutes which I spent discussing with my computer’s memory, I did a small back-of-an-envelope calculation (16 Bit x 9 x 899999999 > 15 TB). So this turned out to be a Bad Idea™.</p><p>The next best thing was to create some random numbers between 100000000 and 99999999. After a bit of experimentation, because I “have no idea of the algorithm” for the purpose of this exercise, I settled on 10000 random fake tax numbers, which corresponded to three seconds overall test runtime on my machine. The code to generate these is wrapped in a testcase for easy access (remember, this is temporary):</p><div>

```javascript
describe('validatePortugueseTaxNumber', () => {
    describe('goldenMaster', () => {
        it('should generate a golden master', () => {
            const gen = random.create('My super Golden Master seed'),
                expectedResultsAndInputs = [ ...new Array(1000000) ].map(() => {
                    const input = gen.intBetween(100000000, 999999999),
                        ...
                });
        }).timeout(10000);
    });
});
```

</div><p><em>Side note:</em> It is often recommended to use a seedable random generator. Since at that point I was not sure whether I wanted to actually save the inputs or not, I ended up using <a href="https://www.npmjs.com/package/random-seed">this PRNG</a> . It’s not strictly necessary for this exercise, though.</p><h4>Step 2: Use These Inputs To Generate A Number Of Outputs.</h4><p>Just call the function.</p><div>

```javascript
...
    const input = gen.intBetween(100000000, 999999999),
        result = validaContribuinte(input.toString(10));
 
        return { input, result };
...
```

</div><h4>Step 3: Record The Inputs And Outputs</h4><p>This also was pretty straightforward. I used the built-in mechanisms of node.js to write the output to a ~3.5MB file.</p><div>

```javascript
fs.writeFileSync('goldenMaster.json', JSON.stringify(expectedResultsAndInputs));
```

</div><p>And just like that, a Golden Master was created.</p><h2>Create a test based on the Golden Master</h2><p>The next step is to use the Golden Master in a test case. For each input, the corresponding output has to correlate to the file.<br /> My test looks like this:</p><div>

```javascript
it('should always conform to golden master test', () => {
    const buffer = fs.readFileSync('goldenMaster.json'),
    data = JSON.parse(buffer);
 
    data.map(({ input, result }) => {
        return expect(validaContribuinte(nextNumber.toString(10))).to.equal(result);
    });
}).timeout(10000);
```

</div><p><em>Side note:</em> I stopped running the Golden Master generation every time; even though it would never produce different results unless the seed changed, it would’ve been a waste of resources to run every time.</p><p>I ran this a couple of times just for the heck of it. Then I started playing around with the code under test, deleting a line here, changing a number there, until I was confident that my Golden Master was sufficiently capturing all the cases. I encourage you to do this, it’s one of the very few times that you get to be happy about red tests.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/49IpI46sRRqMLzb6o8NX"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/49IpI46sRRqMLzb6o8NX" alt="golden master record" width="700" height="146" /></a> </p><p>I was not really satisfied with the output yet. “expected false to equal true” in which case, exactly? Again, in this simple case it would probably not have been necessary, but sometimes it can be useful to also record the failing input. So, after some refactoring, this happened:</p><div>

```javascript
data.map(expectedResult => {
    const { input } = expectedResult;
    const result = validatePortugueseTaxNumber(input.toString(10));
 
    return expect({ input, result}).to.deep.equal(expectedResult);
    });
}).timeout(10000);
```

</div><h2>Refactoring</h2><p>The refactoring itself was pretty straightforward. For the sake of brevity, most of the steps are skipped in this post.<br /> Renaming the function and a few variables:</p><div>

```javascript
export function validatePortugueseTaxNumber(taxNumber) {
// algoritmo de validação do NIF de acordo com
// http://pt.wikipedia.org/wiki/N%C3%BAmero_de_identifica%C3%A7%C3%A3o_fiscal
    let comparator;
    let checkDigitWrong = 0;
 
    const check1 = taxNumber.substr(0, 1) * 9;
    const check2 = taxNumber.substr(1, 1) * 8;
    const check3 = taxNumber.substr(2, 1) * 7;
    const check4 = taxNumber.substr(3, 1) * 6;
    const check5 = taxNumber.substr(4, 1) * 5;
    const check6 = taxNumber.substr(5, 1) * 4;
    const check7 = taxNumber.substr(6, 1) * 3;
    const check8 = taxNumber.substr(7, 1) * 2;
 
    const total = check1 + check2 + check3 + check4 + check5 + check6 + check7 + check8;
    const divisao = total / 11;
    const modulo11 = total - parseInt(divisao) * 11;
    if (modulo11 == 1 || modulo11 == 0) {
        comparator = 0;
    }
    else {
        comparator = 11 - modulo11;
    }
 
    const ultimoDigito = taxNumber.substr(8, 1) * 1;
    if (ultimoDigito != comparator) {
        checkDigitWrong = 1;
    }
 
    if (checkDigitWrong == 1) {
        return false;
    }
    return true;
}
```

</div><p>Simplifying (a lot):</p><div>

```javascript
export function validatePortugueseTaxNumber(taxNumber) {
    const checkSumMod11 = taxNumber.substr(0,8)
                                   .split('')
                                   .map(
                                       (digit, index) => {
                                       return parseInt(digit, 10) * (9 - index);
                                       })
                                   .reduce((a, b) => a + b) % 11,
          comparator = checkSumMod11 > 1? 11 - checkSumMod11 : 0;
 
    return parseInt(taxNumber.substr(8, 1), 10) === comparator;
}
```

</div><p>This is where I stopped.</p><h2>Writing unit tests</h2><p>By now I had a better understanding of what my piece of code did. And, as was said above, it’s a good idea to get rid of a golden master, so the time had come to think about valid test inputs.</p><p>Apparently a remainder of 0 and 1 was important. To this, I added the edge case of remainder 10, and some remainder in the middle range just to be sure. As for generating the corresponding inputs, I cheated a little:</p><div>

```javascript
...
if (checkSumMod11 === 0 && lastDigit === comparator) {
    console.log(taxNumber);
}
...
```

</div><p>Using this generator function, I created the final unit tests for the portugueseTaxNumberValidator:</p><div>

```javascript
describe('validatePortugueseTaxNumber', () => {
    it('should return false for 520363144 (case checkSum % 11 === 0) ', () => {
        expect(validatePortugueseTaxNumber('520363144')).to.equal(false);
    });
 
    it('should return false for 480073977 (case checkSum % 11 === 1) ', () => {
        expect(validatePortugueseTaxNumber('480073977')).to.equal(false);
    });
 
    it('should return false for 291932333 (case checkSum % 11 === 2) ', () => {
        expect(validatePortugueseTaxNumber('291932333')).to.equal(false);
    });
 
    it('should return false for 872711478 (case checkSum % 11 === 10) ', () => {
        expect(validatePortugueseTaxNumber('872711478')).to.equal(false);
    });
 
    it('should return true for 504917951 (case checkSum % 11 === 0) ', () => {
        expect(validatePortugueseTaxNumber('523755600')).to.equal(true);
    });
 
    it('should return true for 850769990 (case checkSum % 11 === 2) ', () => {
        expect(validatePortugueseTaxNumber('998757039')).to.equal(true);
    });
 
    it('should return true for 504917951 (case checkSum % 11 === 10) ', () => {
        expect(validatePortugueseTaxNumber('504917951')).to.equal(true);
    });
});
```

</div><h2>Conclusion</h2><p>Creating a Golden Master and using it during refactoring feels like you’re wrapped in a big, fluffy cotton ball. If the Golden Master record is detailed enough, nothing can go wrong. Or rather, if it does, you will notice in an instant. There are no qualms about deleting code, replacing it with something you think will do the same, because it’s a safe experiment. It was a fun exercise and I would do it again in an instant.</p>

Refactoring Algorithmic Code using a Golden Master Record

<p>In the beginning of January I had the opportunity to attend a very special conference for the second time: <a href="https://codefreeze.fi/" target="_blank">Code Freeze</a> .<br /> It’s special because of the setting: It takes place in northern Lapland, north of the polar circle — in winter (the first and only time I saw the sun was during sunrise on 7th of January. I had to climb Kiilopää mountain for that). It’s also a craft conference, one of the partner conferences of <a href="https://www.socrates-conference.de/" target="_blank">SoCraTes</a> . And it’s one of the most inclusive events I’ve ever attended.<br /> It takes a special kind of crazy to start off the year with a conference in the middle of nowhere, with temperatures going as low as 25 degrees Celsius below zero. Luckily, that was just the one night. It’s exactly this kind of crazy, though, that seems to foster the things that make Code Freeze great: the wonderfully inclusive atmosphere, great talks both technical and non-technical, and connections that outlast the brief camaraderie of other conferences.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/xZtNn0ZPTkaJ3tI1otRH"><img width="700" height="525" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/xZtNn0ZPTkaJ3tI1otRH" alt="Path through trees and snow at Code Freeze" /></a> </p><h2>Is it a conference?</h2><p>Yes and no. Code Freeze is an event which is regarded as a conference by some. It’s considered a holiday with tech talks by others. It’s an unconference in the purest sense of the word — there is little planning except for a <a href="https://trello.com/b/RO5wOXI0/codefreeze-2019" target="_blank">Trello board</a> , and this year there was one marketplace for the entire conference. There are the talks the participants bring, or want to do, and most of them do take the form of discussions, rather than traditional upfront talking-at-people talks; something that should be familiar to anyone who’s ever attended a SoCraTes.</p><h2>So it’s not a conference?</h2><p>That’s also not exactly true. The sessions that do happen are extremely valuable, and usually go deeper than the common “Overview over technology X” talks. They also, sometimes, don’t stop. It’s possible to join a lunch or dinner table discussion about <a href="https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864" target="_blank">Kent Beck’s TCR</a> , or a late-night session about integration testing of AWS cloud services. Or, as some participants did, go from cabin to cabin late at night in order to bring the Freifunk Wifi to Code Freeze. Or have a discussion about child education, with input from a trainer for nonviolent communication.</p><h2>Inclusivity</h2><p>I’ve mentioned before that Code Freeze is a very inclusive conference. Since it is in a beautiful holiday location, a lot of people bring their spouses. They also contribute content which is interesting for people looking to broaden their horizons. For example, the talk about the Internet as a workplace for people with invisible disabilities.</p><p>Some people even bring their whole families. It’s amazing to have a technical conference where the parts of life that are so often hidden in our professional lives are not only included, but celebrated.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/z9A5pSXCRIGFMhh0F9mK"><img loading="lazy" width="700" height="525" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/z9A5pSXCRIGFMhh0F9mK" alt="photographers on a field of snow, rising sun in background" /></a> </p><h2>Code Freeze highlights</h2><p>This wouldn’t be a post-conference writeup if I didn’t share some of my personal highlights, though in reality, there were too many to mention everything. Sessions inside the sauna. Sessions that were streamed to include people who couldn’t attend physically (in some cases because they were in the sauna). A three-people call-for-help session where I learned more about Spring Boot testing (thanks to <a href="https://twitter.com/AmelieCornelis" target="_blank">Amélie</a>  andChristian) than I’d thought possible in such a short time. <a href="https://twitter.com/AnnNat" target="_blank">Natalie’s</a>  talk on the Internet as a workplace. <a href="https://twitter.com/Singsalad" target="_blank">Franzi’s</a>  “how do we make this more inclusive for parents with kids” session. The sponaneous “let’s create a code of conduct” session with a lot of input from<a href="https://twitter.com/offbyoni" target="_blank">Toni</a> , which coincidentally resulted in a CoC that was very close to the one for SoCraTes Germany. If I had to pick the most amazing events, though, I’d pick the Achitectural Katas and the Ideal Company fishbowl.</p><h3>Architecture Katas</h3><p><a href="https://twitter.com/nelisboucke" target="_blank">Nelis Boucke</a>  facilitated two workshops on Neal Ford’s <a href="http://nealford.com/katas/" target="_blank">Architectural Katas</a>  at this Code Freeze. Architectural Katas are not aimed at building better architectures by repeating the same task over and over again — rather, the goal is to get better at talking about architecture, a skill every one of us will need at some point in their lives. We only had two hours, but focusing on learning the specific method we used (<a href="https://c4model.com/" target="_blank">the C4 Model</a> ) in describing an architecture for a mock project, and reflecting afterwards about what we could’ve done better, was an incredibly rewarding (and humbling) experience. We got to see, in a controlled training environment, how we each approach the problem from different angles, where that leads to clashes, and how to work with that in a discussion.</p><h3>Your Ideal Company fishbowl</h3><p>The other thing that resonated deeply was the fishbowl about what constitutes an ideal company. Sparked by Chris’ tweet here (https://twitter.com/c089/status/1074206407359168512), we went on a journey where we discovered mostly that we didn’t agree on much. Almost everyone agreed that there was a common baseline, both in the positive sense as well as in the negative (red flags) — but even that baseline, things every company should have or avoid, was fluid and depended on personal preferences (though a safe bet seems to be chairs that don’t lead to back pain). The general consensus seemed to be that ideally, before choosing to be employed somewhere, everyone audits the company according to their own preferences, needs and wants. Which is not that surprising, but has an interesting turnaround for companies trying to hire software developers: The more open and honest a company is about their ideals, working environment, and atmosphere, the more likely they are to attract the people who work there and want to stay.</p><h2>People at Code Freeze</h2><p>The real highlight, though, were the people I met, too many to name everyone. The organizers <a href="https://twitter.com/rinkkasatiainen" target="_blank">Aki Salmi</a>  and <a href="https://twitter.com/coderbyheart" target="_blank">Markus Tacker</a>  deserve special thanks, as do all of the people who contributed content — both people whose sessions I could attend, and people for whose sessions I unfortunately did not have time. Many, many good talks, both in formal and informal sessions. And just the overall sense of well-being that comes from just being there as part of a community.</p><p>Code Freeze was an unique experience, and one I already sorely miss. Thanks to everyone who made it possible.</p>

Code Freeze

Lass uns austauschen!

Möchtest du dich über Vibe Coding austauschen?

Vibe coding – Was nun?

**Kann man mit KI wirklich Anwendungen erzeugen, ohne selbst coden zu können, mit einem Bruchteil des Aufwands und der Zeit?**

"Gib dich dem *Vibe* hin! Erstelle Software nur mit natürlicher Sprache! GenAI ist der *Builder*. Hör auf, dich zu beschweren und fang mit builden an!" So oder so ähnlich liest man es neuerdings in den Sozialen Medien. 

Was ist dran an dem "vibe coding"? 

Der Begriff "vibe coding" wurde von [Andrej Karpathy in einem Tweet Anfang Februar 2025](https://x.com/karpathy/status/1886192184808149383) geprägt. Andrej war Direktor für Künstliche Intelligenz bei Tesla und hat davor und danach für OpenAI an ChatGPT gearbeitet. Sicher weiß der Mann, wovon er spricht.

In seinem Tweet beschreibt er, was er mit "vibe coding" meint: Sich nicht um den Code kümmern, sondern ausschließlich KI-gestützte Werkzeuge nutzen. Alle Vorschläge der KI immer annehmen, Fehlermeldungen 1:1 einfach an die KI geben und diese den Fehler beheben lassen. Er beschreibt diese Art, Software zu entwickeln, begeistert und in leuchtenden Farben.

Wichtig ist, den Begriff "vibe coding" abzugrenzen: Nicht jeder Einsatz von Generativer KI (GenAI oder einfach nur KI) ist "vibe coding". Wer Copilot, ChatGPT, Claude, aber auch Cursor oder Windsurf und so weiter nur als eines von vielen Werkzeugen nutzt, um Code zu schreiben, zu verändern oder zu verstehen, der ist noch lange kein "vibe coder". Mit diesem speziellen Begriff ist ausschließlich eine Arbeitsweise mit GenAI gemeint, bei der man sich gar nicht oder fast gar nicht um den erzeugten Code kümmert. Das ist dann die Aufgabe der KI.

Seit dem Tweet von Andrej Karpathy ist der Begriff “vibe coding” überall im Netz zu finden. Allerdings sind die Reaktionen häufig nicht besonders positiv. Die Memes reichen von Witzen:


![vibe-coding-meme1.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cm8kf56lwwnsv07up1g7z0psv)

bis zu eher katastrophalen Meldungen:

![vibe-coding-meme2.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cm8kf766mvs3g07un67a6fipb)

Wie kann das sein? Wieso kann etwas, das ein echter Profi derartig anpreist, eine so  ablehnende Reaktion hervorrufen oder gar katastrophale Wirkung haben? Kommen diese Memes nur von Entwicklern, die um ihren Job fürchten?

Schauen wir einmal an dem Hype vorbei und werfen einen Blick darauf, welche Werkzeuge es gibt, was KI-gestützte Softwareentwicklung kann und was sie vielleicht auch (noch) nicht kann.

### Die Agenten kommen

GenAI à la ChatGPT – also einfach einen Prompt eingeben und eine Antwort erhalten – war gestern. Die nächste Generation von KI-Tools sind sogenannte Agentensysteme. Das sind Lösungen, die KI nutzen, um einen Plan zu erstellen, der dann Schritt für Schritt durch "klassische Tools" und auch KI abgearbeitet wird. Prominente Vertreter dieser Gattung für Softwareentwicklung sind [Cursor](https://www.cursor.com/), [Windsurf](https://codeium.com/windsurf) oder auch [V0](https://v0.dev/) und seit Neuestem auf [Github Copilot](https://github.com/features/copilot) mit dem Agenten-Modus.

Derartige Agenten-KI-Tools können selbstständig Programmcode lesen, Vereinbarungen in der Architekturdokumentation nachschlagen, Code entsprechend der Vorgaben erstellen oder ändern, Compile-Fehler korrigieren und auch Tests schreiben und ausführen.

Zwar kann eine solche Aktion etliche Minuten dauern (und viele Token in den KI verbrauchen, die viele Euro kosten), liefert dann aber bedeutend hochwertigere Lösungen als der "einfache" Dialog mit einer KI. Das kann im Einzelfall die Arbeit von Stunden oder vielleicht sogar Tagen ersetzen.

Ich persönlich erwarte, dass sich die Qualität der eigentlichen KI-Modelle (ChatGPT, Claude etc.) in der näheren Zukunft nicht deutlich weiter steigern wird, wohl aber die Qualität der Agenten, die KI mit klassischer Automatisierung kombinieren.

### Die Stärken und Schwächen von GenAI in der Softwareentwicklung

Ich arbeite seit über einem Jahr in Kundenprojekten mit Github Copilot und habe in meiner Freizeit bereits eine Menge an (Agenten-) KI-Werkzeugen ausprobiert. Daneben habe ich mich mit meinen Kolleginnen und Kollegen ausgetauscht, die ebenfalls Erfahrungen mit KI-unterstützter Entwicklung haben. Die Bilder decken sich:

Zu den **Stärken von GenAI / KI in der Softwareentwicklung** gehören demnach:

- **Übernehmen von repetitiven Aufgaben**<br/> Beispiele sind das wiederholte Füllen von Datenstrukturen oder Durchführen von Mappings, sowie das Aufsetzen von Grundgerüsten für Softwarekomponenten.
- **Zugriff auf gelöste Probleme**<br/>Damit ist gemeint, dass es in vielen Fällen schneller und nützlicher ist, eine KI nach einer Lösung für ein Problem zu fragen, als die Suchmaschine der Wahl anzuwerfen oder in Stackoverflow nachzuschauen. Besonders, wenn die KI Zugriff auf den eigenen Code hat (als Plugin in der IDE), ist die Lösung häufig besser auf die eigene Situation zugeschnitten als alles, was man im Netz finden kann.
- **Erzeugen von kreativen Lösungen**<br/>Manchmal liefert die KI für eine Aufgabe eine besonders effektive oder effiziente Lösung, an die man selbst gar nicht gedacht hätte. Mit dem oben vorgestellten V0 kann man sich z. B. Vorschläge für UI oder sogar ganze UX Flows erzeugen lassen.
- **Erstellen einzelner Module oder Funktionen**<br/>Ist eine gewünschte Funktionalität einfach und vollständig zu beschreiben, können KI-Lösungen hier eine Menge hilfreicher Programmzeilen bauen.

Das liest sich beeindruckend und das ist es auch. Generative KI ist in den letzten zwei Jahren extrem gut geworden – auch im Rahmen der Softwareentwicklung. Ist also der Hype um "vibe coding" gerechtfertigt? Ersetzt die KI im Agentensystem die Softwareentwickler?

Nun, um diese Frage zu beantworten, müssen wir auch einen Blick auf die Schwächen von KI werfen. Diese Liste gilt auch für Agentensysteme:

- **Beherrschen von Komplexität.** <br/> Wenn eine Software wächst, steigt die Menge an Informationen, Regeln, Absprachen etc., die berücksichtigt werden müssen,  in der Regel nicht linear, sondern nahezu exponentiell. Eine KI kann diese Menge irgendwann nicht mehr berücksichtigen und beachten. Diese Schwäche gleichen die o. g. Tools durch immer größere Kontexte aus, sowie durch spezielle Dateien, die im Projekt liegen können, in denen man z. B. Coding Richtlinien hinterlegen kann.<br/>Komplexität ist also im Moment noch ein Problem, aber es kann in der Zukunft kleiner werden. Ich persönlich bin aber nicht davon überzeugt, dass an dieser Stelle KI den Menschen überholen wird. Mal sehen.
- **Korrekte Funktionsweise sicherstellen** <br/>KI versteht nicht, was sie selbst tut. Im Kern wird immer nur das nächste Wort oder das nächste Stück Code erzeugt. KI kann also niemals vollständig verhindern, dass Aktionen unerwünschte Nebenwirkungen haben. Je komplexer eine Anwendung aber ist, desto aufwändiger und fehleranfälliger ist es, manuell die korrekte Funktionsweise sicherzustellen. Automatisierte Tests können hier helfen, aber man muss in einem solchen Fall die Tests anders schreiben, als man es derzeit tut, um den selbst geschriebenen und damit bekannten Code zu testen.
- **Der Output von KI ist nicht deterministisch.** <br/>Die große Stärke von KI, nämlich die (gefühlte) Kreativität, ist gleichzeitig eine große Schwäche. Wie weiter oben gesagt, kann KI z. B. das Grundgerüst für neue Komponenten erstellen. Dabei ist es aber möglich bis wahrscheinlich, dass manche dieser Komponenten unterschiedlich strukturiert werden. Zwar funktionieren sie, aber sie sind nicht miteinander vergleichbar. Je öfter man dann diesen Code ändern lässt (z. B. durch neue Anforderungen), desto mehr driften die unterschiedlichen Code-Teile auseinander.
- **Wartbarkeit** <br/>Eng mit dem Punkt davor verbunden ist zunehmend auffällig, dass KI-generierter Code schwerer wartbar ist als Code, der einen vernünftigen 4-Augen-Review-Prozess durchlaufen hat. Das hat zur Folge, dass es nach dem "vibe coding" schwerer ist, die Anwendung zu ändern oder zu erweitern.
- **Berücksichtigung von Qualitätsanforderungen wie z. B. Betriebssicherheit, IT-Sicherheit, vernünftiger Umgang mit Ressourcen etc.**<br/>KI-Systeme haben anhand von Code aus dem Internet "programmieren gelernt". Ein großer Teil dieses Codes berücksichtigt die oben genannten Qualitätsanforderungen nicht (ausreichend) und die KI demnach auch nicht. Das liegt daran, dass ein Großteil des Programmierwissens der KIs aus Tutorials oder Anleitungen gezogen wird. Und in denen ist IT-Security oder ressourcenschonender Umfang häufig kein Thema. <br/>Besonders kritisch wird es, wenn jemand, der oder die selbst keine Ahnung von IT hat, eine Lösung ins Netz stellt, die genau diese Anforderungen nicht berücksichtigt hat. Potenzielle Angreifer haben so leichten Zugriff auf unsichere Systeme; die Folgen sind nicht abzuschätzen, aber möglicherweise gravierend. Das zweite oben dargestellte Meme zeigt dieses Problem deutlich. (Ich hoffe sehr, dass das nicht wirklich passiert ist.)

## Was ist denn nun richtig? KI einsetzen oder nicht?

Die vorherige Gegenüberstellung zeigt das aktuelle Dilemma. Manch einer sieht vor allem die Stärken und proklamiert den Untergang des Berufsstandes der Softwareentwickler, andere möchten KI am liebsten überhaupt nicht nutzen.

Ich denke, in beiden Standpunkten liegt ein Kern der Wahrheit. Ich persönlich würde folgende Bewertung vornehmen:

- Mithilfe von KI kann man sehr schnell und effizient *bestimmten* Code erzeugen.
- Es ist erstaunlich, wie gut und kreativ die Lösungen manchmal sind.
- Es macht Spaß, mit diesen Werkzeugen zu arbeiten, wenn man den Umgang einmal gelernt hat.

Aber: 

- Gerade bei großen Anwendungen (also eigentlich alle, die wir im Kundenauftrag erstellen) gerät man sehr schnell an Grenzen, wo die KI nur noch wenig helfen kann oder sogar Schaden anrichtet.
- Kaum jemand würde den Code 1:1 in Produktion übernehmen. In jedem Fall muss man sich den Code sehr gründlich und kritisch anschauen – kritischer, als man den Code einer Kollegin oder eines Kollegen prüfen würde.

## Hat Andrej Karpathy also unrecht?

Nein, hat er nicht. Denn die meisten Leute übersehen einen sehr wichtigen Satz in seinem Tweet: "*It's not too bad for throwaway weekend projects, but still quite amusing.*" Er selbst beschreibt "vibe coding" also als Methode und Werkzeug für **Wegwerfprojekte am Wochenende**. Kein Satz darüber, dass er hier an den echten, produktiven Einsatz denkt.

Das entgeht vielen offenbar.

Beachtet man die vorgenannten Risiken des vibe codings, sehe ich persönlich durchaus ein paar professionelle Einsatzgebiete:


- **Rapid prototyping**<br/>
Mit Agenten-KI kann man sehr leicht Beispielanwendungen bauen, die viel mehr sind als reine Klick-Dummys. Man kann sie für Anwendertests einsetzen oder um Stakeholdern “anfassbare” Lösungsansätze zu präsentieren, nicht aber, um sie in Produktion zu bringen.
- **Ideen generieren**<br/>Gerade Tools, die auch UIs erzeugen, können sehr hilfreich sein, um in der Discovery Phase die Lösung iterativ zu erkunden.
- **Erstellen einzelner Code-Blöcke und Module**<br/>Gerade, wenn etwas mit ein paar Sätzen vollständig beschreibbar ist, können solche Tools auch produktiven Code erzeugen. Nur muss man ihn gründlich prüfen.

Und was ist mit den kühnen Behauptungen, dass KI die Softwareentwickler überflüssig macht?

Um die Frage zu beantworten schaue man sich am besten an, *wer* solche Behauptungen aufstellt und welche Ziele die Person verfolgt: Sind es es Toolhersteller, die das nächste KI-Werkzeug verkaufen wollen (wobei die meisten von ihnen mittlerweile vorsichtiger argumentieren)? Ist es die Geschäftsleitung, die einen Personalabbau begründen will? Sind es Menschen im Fachbereich, die von KI gehört haben, und die Lösungen eher morgen als übermorgen haben möchten? Oder sind es Anfänger in der Softwareentwicklung, die meinen, man könnte die Lernkurve auf diese Weise abkürzen?

Bisher jedenfalls habe ich keine solche Behauptung von einem erfahrenen Softwareentwickler oder einer Softwareentwicklerin gehört.

Nun könnte man sagen, das seien ja auch genau diejenigen, die ersetzt werden sollen. Das stimmt prinzipiell. Aber es sind auch die einzigen, die eine professionelle Einschätzung geben können. Und – nicht zu vergessen: Die meisten meiner Kolleginnen und Kollegen nutzen die KI-Tools oft und gerne. Wir fühlen uns nicht bedroht durch die Technik. Die Bedrohung kommt – wenn überhaupt – von Entscheidungsträgern, die den überzogenen Behauptungen mehr glauben als ihren eigenen Kolleginnen und Kollegen.

## Fazit

Ich schließe mich Andrej Kaparthy an, "vibe coding" kann eine spannende und lustige Wochenendbeschäftigung und – manchmal – in kleinen Dosen auch im professionellen Umfang nützlich sein.

Niemals allerdings würde ich damit eine Anwendung live setzen. Mein Geld, meine Reputation und meine Sicherheit wären mir dafür viel zu kostbar.



Illustration von Mensch-Maschinen-Hybriden vor Computern

LEISTUNGEN

Generative KI: Potenzialanalyse und Umsetzung 

Senior Agile Consultant

it-daily.net

Softwareentwicklung

Schreibt in Zukunft nur noch KI unsere Software?

Hier gibt's noch mehr spannende Infos von uns für euch

Vibe Coding. Wenn KI Code schreibt: Wie viel Mensch braucht moderne Software noch?

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Wenn KI Code schreibt: Wie viel Mensch braucht moderne Software noch?

Aus dem Inhalt:

Hier gibt's noch mehr spannende Infos von uns für euch

Vibe coding – Was nun?

Generative KI: Potenzialanalyse und Umsetzung

Schreibt in Zukunft nur noch KI unsere Software?

Jetzt für unseren Newsletter anmelden