Wann Software-Entwicklung Handwerk ist und wann Gewerbe

Die zwei Gesichter der Software-Entwicklung

24.01.2026, Von Stephan Schwab

Software-Entwicklung bewegt sich zwischen zwei Modi: Handwerk, wo erfahrene Fachleute in neuartigen Situationen Ermessensentscheidungen treffen, und Gewerbe, wo etablierte Muster bekannte Probleme lösen. Das Verständnis, welcher Modus zutrifft — und wann zwischen ihnen gewechselt werden sollte — bestimmt, ob Organisationen angemessen investieren, ob Modernisierungsprojekte gelingen und ob Entwickler Zufriedenheit in ihrer Arbeit finden.

Was diese Begriffe wirklich bedeuten

Im Deutschen haben wir das Glück, dass unsere Sprache eine wichtige Unterscheidung bewahrt, die in anderen Sprachen oft verschwimmt. Bei uns ist die Grenze zwischen Handwerk und Gewerbe klarer — und das Verständnis dieser Unterscheidung erhellt, worum es hier eigentlich geht.

Handwerk bezeichnet die traditionellen, regulierten, hochqualifizierten manuellen Berufe. Der Weg zur Meisterschaft ist lang: eine formale Lehre von etwa drei Jahren, gefolgt von mehreren Jahren als Geselle — traditionell auf Wanderschaft, um bei verschiedenen Meistern zu lernen — bevor man schließlich zur Meisterprüfung zugelassen wird. Der Zimmerer, der Elektriker, der Goldschmied, der Bäckermeister — sie alle üben Handwerk aus. Das Wort trägt Respekt und Anerkennung in sich. Es beschreibt Berufe, in denen Urteilsvermögen, Tradition und tiefes Können zusammenfließen — erworben über viele Jahre.

Gewerbe oder Beruf im allgemeineren Sinne beschreibt Arbeit, die schneller erlernt werden kann — manchmal durch eine kürzere Ausbildung, manchmal durch Anlernen am Arbeitsplatz. Montagearbeit, Maschinenbedienung, viele Lagertätigkeiten. Wertvolle Arbeit, gewiss, aber Arbeit, bei der die Muster etabliert sind und das Können vor allem in der zuverlässigen Ausführung liegt, weniger im Urteilsvermögen.

Diese Unterscheidung ist für Software wichtig, weil beide Modi in unserem Feld existieren — oft innerhalb desselben Projekts oder sogar am selben Tag. Die Frage ist nicht, welcher besser ist — beide sind notwendig — sondern welcher auf die jeweilige Arbeit zutrifft.

Ein Tischlermeister erfindet die Schwalbenschwanzverbindung nicht neu

Wenn Sie eine Möbelwerkstatt betreten, können Sie etwas Lehrreiches beobachten. Der Tischlermeister, der Schwalbenschwanzverbindungen für eine Schublade schneidet, erfindet die Verbindung nicht jedes Mal neu. Jahrhunderte der Holzbearbeitungstradition haben optimale Winkel, Abstände und Techniken etabliert. Die Fähigkeit liegt in der Ausführung — präzise Schnitte, enge Passungen, geeignete Holzauswahl — nicht im Neuerfinden dessen, was eine Schwalbenschwanzverbindung sein sollte.

Doch wenn derselbe Tischler einen ungewöhnlichen Auftrag erhält — vielleicht Möbel, die sich auf unkonventionelle Weise zusammenfalten müssen, oder eine geschwungene Oberfläche, die Standardtechniken nicht abdecken — verschiebt sich die Arbeit. Nun übernehmen Urteilsvermögen, Experimentieren und kreative Problemlösung. Der Tischler führt nicht mehr bekannte Lösungen aus, sondern entdeckt neue.

Software-Entwicklung funktioniert genauso. Ein Großteil der Entwicklung ist nicht neuartig. Authentifizierungssysteme, Datenbankabfragen, Formularvalidierung, Schnittstellen-Integrationen — das sind Schwalbenschwanzverbindungen. Wir wissen, wie sie funktionieren. Die Muster sind etabliert. Die Fähigkeit liegt in der zuverlässigen Ausführung: sauberen Code schreiben, Randfälle ordnungsgemäß behandeln, gründlich testen, sicher ausliefern.

Gewerbliche Arbeit ist keine geringere Arbeit

Etwas als „gewerbliche Arbeit” zu bezeichnen, trägt in Software-Kreisen leider negative Konnotationen. Entwickler sehen sich oft gerne als kreative Problemlöser, nicht als Arbeiter, die Blaupausen folgen. Aber diese Sicht verkennt sowohl den Wert gewerblicher Arbeit als auch die Realität dessen, was die meiste Software-Entwicklung erfordert.

Ein erfahrener Elektriker, der ein Haus verkabelt, folgt etablierten Normen und Mustern. Niemand würde das als unkreativ oder unwichtig abtun. Die Arbeit erfordert Fachwissen, Liebe zum Detail und Stolz darauf, Dinge ordnungsgemäß zu tun. Leben hängen von korrekter Ausführung ab. Das Gleiche gilt für einen Großteil der Software-Entwicklung.

Wenn ein Entwickler eine Standard-REST-Schnittstelle implementiert, Modultests für eine Dienst-Schicht schreibt oder eine Auslieferungs-Pipeline konfiguriert, leistet er gewerbliche Arbeit. Er wendet bekannte Muster zuverlässig an. Diese Arbeit hält Unternehmen am Laufen. Sie dient Kunden. Sie erfordert Können und Sorgfalt. Sie abzuwerten bedeutet, die Beiträge unzähliger Entwickler zu schmälern, die die Systeme bauen und warten, von denen unsere Wirtschaft abhängt.

Wann Handwerk entsteht

Handwerkliche Arbeit in der Software entsteht aus echter Neuartigkeit — aber Entwickler müssen ehrlich sein, was als neuartig gilt.

Eingebildete Neuartigkeit ist verbreitet: Ein Entwickler überzeugt sich selbst, dass seine Situation einzigartig ist, und baut dann eine maßgeschneiderte Lösung für ein Problem, das etablierte Werkzeuge bereits gut bewältigen. Er erstellt ein eigenes Authentifizierungssystem, obwohl OAuth existiert, schreibt eine selbstentwickelte Datenbankabstraktionsschicht, obwohl ausgereifte Rahmenwerke verfügbar sind, oder entwirft ein eigenes Nachrichtenformat, obwohl JSON ausreichen würde. Das passiert oft, weil es interessanter erscheint, etwas Neues zu bauen, als etwas Bestehendes anzuwenden — oder weil der Entwickler nicht vollständig erkundet hat, was bereits verfügbar ist.

Echte Neuartigkeit ist anders. Sie haben die etablierten Ansätze wirklich bewertet und festgestellt, dass sie nicht passen. Ihre fachlichen Randbedingungen sind ungewöhnlich, die Integrationsgrenzen sind einzigartig, oder die Leistungsanforderungen übersteigen das, was Standardlösungen liefern können. In diesen Situationen ist handwerkliche Arbeit notwendig — nicht weil sie prestigeträchtiger ist, sondern weil kein fertiges Muster passt.

Echte handwerkliche Arbeit finden Sie an mehreren Stellen:

Fachliche Komplexität, die Standardmustern trotzt. Wenn die Geschäftsdomäne echte Komplexität aufweist — Finanzderivate mit einzigartigen Risikomerkmalen, Fertigungsprozesse mit ungewöhnlichen Einschränkungen, Logistikprobleme mit neuartigen Optimierungskriterien — passen Standardlösungen nicht. Entwickler müssen die Domäne tiefgehend verstehen und Ansätze erfinden, die auf ihre spezifischen Herausforderungen zugeschnitten sind.

Systemintegration über ungewöhnliche Grenzen hinweg. Systeme verbinden, die nicht für die Zusammenarbeit konzipiert wurden, Brücken zwischen Altsystemen und modernen Architekturen bauen, unterschiedliche Datenmodelle in Einklang bringen — diese Situationen erfordern kreative Problemlösung. Die Muster zur Verbindung von System A mit System B existieren nicht, weil noch niemand genau diese Systeme verbunden hat.

Leistung in ungewöhnlichen Größenordnungen. Wenn ein System Lasten oder Datenmengen bewältigen muss, die über gängige Erfahrungen hinausgehen, können Standardansätze versagen. Handwerkliche Arbeit entdeckt, was in diesen spezifischen Umständen funktioniert.

Innovation im Nutzererlebnis. Wirklich neue Wege zu schaffen, wie Menschen mit Systemen interagieren, erfordert Handwerk. Nicht die oberflächliche Neuheit anderer Schaltflächenfarben, sondern grundsätzliches Neudenken dessen, wie Nutzer Ziele erreichen.

Die Gefahr der Fehlklassifizierung

Organisationen geraten in Schwierigkeiten, wenn sie Arbeit in beide Richtungen falsch klassifizieren.

Gewerbliche Arbeit als Handwerk behandeln führt zu Überentwicklung, aufgeblähten Zeitplänen und unnötiger Komplexität. Jede Funktion wird zum Forschungsprojekt. Entwickler bauen maßgeschneiderte Lösungen für Probleme, die Standardwerkzeuge bereits perfekt lösen. Einfache Anwendungen schwellen zu architektonischen Monumenten an. Technische Schulden entstehen nicht durch Abkürzungen, sondern durch überelaborierte Lösungen, die niemand warten kann.

Handwerkliche Arbeit als Gewerbe behandeln führt zu gescheiterten Projekten und verpassten Chancen. Organisationen erwarten vorhersehbare Zeitpläne für von Natur aus unvorhersehbare Arbeit. Sie drängen Entwickler, sich auf Fristen festzulegen, bevor die Erkundung offenbart hat, was die Arbeit tatsächlich erfordert. Teams implementieren den ersten Ansatz, der machbar erscheint, anstatt den Ansatz zu entdecken, der tatsächlich passt.

Die Signale lesen

Woher wissen Sie, welcher Modus zutrifft? Mehrere Signale helfen:

Wurde dieses Problem schon oft gelöst? Wenn erfahrene Entwickler das Muster sofort erkennen und den Standardansatz benennen können, handelt es sich wahrscheinlich um gewerbliche Arbeit. Wenn sie die Stirn runzeln, klärende Fragen stellen und Erkundungs-Spikes vorschlagen — handwerkliche Arbeit.

Gibt es etablierte Bibliotheken und Werkzeuge dafür? Reichhaltige Ökosysteme von Bibliotheken deuten auf gewerbliche Arbeit hin — andere sind diesem Problem häufig genug begegnet, dass Lösungen paketiert wurden. Spärliche Optionen deuten auf handwerkliches Territorium hin.

Können Sie mit Zuversicht schätzen? Gewerbliche Arbeit unterstützt einigermaßen genaue Schätzungen, weil die Muster bekannt sind. Handwerkliche Arbeit widersteht Schätzungen, weil die Entdeckung noch nicht stattgefunden hat. Wenn Teams nicht zuversichtlich schätzen können, ist das ein Signal über die Natur der Arbeit, nicht über die Kompetenz des Teams.

Treibt die Geschäftsdomäne die Komplexität? Wenn Komplexität aus der Geschäftsdomäne kommt statt aus technischen Anforderungen, ist handwerkliche Arbeit wahrscheinlicher. Technische Komplexität wurde oft schon gelöst; fachliche Komplexität ist spezifisch für diese Situation.

Modernisierung: Wo beide Modi aufeinandertreffen

Ein erheblicher Teil der Software-Arbeit besteht weder aus dem Aufbau neuer Systeme von Grund auf noch aus der Wartung stabiler Systeme. Viele Entwickler verbringen ihre Tage damit, bestehende Systeme zu modernisieren — alternde Architekturen zu verbessern, Altkomponenten zu ersetzen oder auf neue Plattformen zu migrieren. Diese Arbeit verdient besondere Aufmerksamkeit, weil sie Handwerk und Gewerbe auf besondere Weise verbindet.

Das bestehende System zu verstehen ist Handwerk. Altsysteme kommen selten mit akkurater Dokumentation. Die Entwickler, die sie gebaut haben, sind oft weitergezogen. Der Code verkörpert Entscheidungen, die unter vergessenen Randbedingungen getroffen wurden, Umgehungslösungen für Probleme, an die sich niemand erinnert, und Integrationen mit Systemen, die sich selbst weiterentwickelt haben. Das zu verstehen — nicht nur was der Code tut, sondern warum er es so tut — erfordert Untersuchung, Hypothesenbildung und Urteilsvermögen. Kein etabliertes Muster sagt Ihnen, wie Sie ein bestimmtes Altsystem verstehen sollen.

Zu entscheiden, was bewahrt und was geändert werden soll, ist Handwerk. Nicht alles in einem Altsystem ist technische Schuld. Manche scheinbare Komplexität spiegelt echte Geschäftsanforderungen wider, die neue Entwickler noch nicht verstehen. Manche scheinbare Ineffizienzen existieren, weil schnellere Ansätze unter Produktionslast versagt haben. Das Handwerk liegt darin, wertvolle Komplexität von zufälliger Komplexität zu unterscheiden, zu erkennen, welche Verhaltensweisen exakt bewahrt werden müssen und welche neu gedacht werden können.

Der eigentliche Ersatz folgt oft gewerblichen Mustern. Sobald Sie verstehen, was das neue System tun muss, kann ein Großteil des Bauens unkompliziert sein. Eine moderne REST-Schnittstelle zu implementieren, die einen veralteten SOAP-Dienst ersetzt, verwendet etablierte Muster. Daten von einem Schema in ein anderes zu migrieren, folgt bekannten Ansätzen. CI/CD-Pipelines für das neue System einzurichten, ist gewerbliche Arbeit. Die Neuartigkeit lag darin zu verstehen, was gebaut werden soll; das Bauen selbst kann Routine sein.

Aber Integration und Migration erfordern wieder Handwerk. Alte und neue Systeme parallel zu betreiben, den Datenverkehr schrittweise zu verlagern, die Randfälle zu behandeln, in denen sie sich unterschiedlich verhalten — das erfordert Urteilsvermögen und Kreativität. Jede Migration hat einzigartige Eigenschaften. Die etablierten Muster für Strangler-Fig-Migrationen oder Parallelbetrieb bieten Ausgangspunkte, aber die konkreten Entscheidungen darüber, was wann migriert werden soll, wie die Datensynchronisation gehandhabt wird und wann umgeschaltet werden soll, erfordern handwerkliches Urteilsvermögen.

Organisationen unterschätzen Modernisierungsprojekte oft, weil sie „Altsystem durch modernes Äquivalent ersetzen” sehen und gewerbliche Arbeit annehmen. Das verborgene Handwerk — das Altsystem verstehen, Ermessensentscheidungen darüber treffen, was bewahrt werden soll, den Übergang navigieren — ist der Punkt, an dem Projekte ins Stolpern geraten.

Beide Modi erfordern Fachwissen

Ein häufiger Fehler ist die Annahme, dass handwerkliche Arbeit Fachwissen erfordert, gewerbliche Arbeit aber nicht. Beide Modi verlangen Können — unterschiedliche Arten von Können.

Gewerbliche Arbeit erfordert:

• Tiefes Wissen über etablierte Muster und wann sie anzuwenden sind
• Disziplin, konsequent und gründlich auszuführen
• Aufmerksamkeit für Randfälle, die Musterbeschreibungen oft auslassen
• Teststrenge zur Überprüfung korrekter Implementierung
• Kommunikationsfähigkeiten zur Koordination mit anderen Fachleuten

Handwerkliche Arbeit erfordert:

• Fähigkeit zu erkennen, wann Standardmuster nicht passen
• Kreativität, um neuartige Lösungen zu entwickeln
• Demut, um zu erkunden und zu überarbeiten, wenn Ansätze nicht funktionieren
• Urteilsvermögen zu wissen, wann die Entdeckung genug offenbart hat, um fortzufahren
• Kommunikationsfähigkeiten, um unbekannte Ansätze Stakeholdern zu erklären

Was das für Organisationen bedeutet

Das Verständnis dieser beiden Modi hilft Organisationen, bessere Entscheidungen zu treffen:

Angemessen besetzen. Gewerbliche Arbeit profitiert von Entwicklern, die Zufriedenheit in zuverlässiger Ausführung finden und Stolz auf gut umgesetzte Standardmuster empfinden. Handwerkliche Arbeit profitiert von Entwicklern, die in Mehrdeutigkeit und neuartigen Herausforderungen aufblühen. Fehlanpassungen erzeugen Frustration auf beiden Seiten.

Erwartungen richtig setzen. Gewerbliche Arbeit sollte mit vorhersehbaren Zeitplänen und zuverlässigen Schätzungen kommen. Handwerkliche Arbeit sollte mit ausdrücklicher Anerkennung von Unsicherheit kommen und iterativen Ansätzen, die den Umfang offenbaren, während die Arbeit fortschreitet.

Proportional investieren. Gewerbliche Arbeit sollte Standardwerkzeuge und etablierte Bibliotheken nutzen. Handwerkliche Arbeit kann maßgeschneiderte Lösungen rechtfertigen — aber nur wenn die wirklich neuartigen Aspekte es erfordern.

Übergänge erkennen. Arbeit beginnt oft als Handwerk und wird zum Gewerbe. Die erste Implementierung eines neuartigen Systems beinhaltet erhebliche Entdeckungsarbeit. Nachfolgende Wartung und Erweiterung können größtenteils gewerbliche Arbeit sein — Anwendung etablierter Muster innerhalb eines nun verstandenen Systems. Personal und Erwartungen sollten sich entsprechend anpassen.

Das ehrliche Gespräch

Vielleicht am wichtigsten: Organisationen und Entwickler sollten ehrliche Gespräche darüber führen, welcher Modus auf ihre Arbeit zutrifft. Entwickler, die gewerbliche Arbeit als Handwerk darstellen — weil Handwerk prestigeträchtiger erscheint — erweisen sich und ihren Organisationen einen Bärendienst. Organisationen, die darauf bestehen, dass alle Arbeit Gewerbe ist — weil Gewerbe vorhersehbarer ist — schaffen Bedingungen für Misserfolg.

Der Tischlermeister empfindet keine Scham dabei, Schwalbenschwanzverbindungen gut zu schneiden. Die Zufriedenheit kommt aus der Qualität der Ausführung, aus dem Beitrag zu etwas Nützlichem, aus dem Stolz auf ordentlich geleistete Arbeit. Derselbe Tischler empfindet andere Zufriedenheit beim Lösen eines ungewöhnlichen Problems — die Aufregung der Entdeckung, die Kreativität des Erfindens von Ansätzen, die Belohnung, etwas wirklich Neues zu schaffen.

Beide Arbeitsformen haben Würde. Beide erfordern Fachwissen. Beide tragen Wert bei. Die Weisheit liegt darin zu erkennen, welcher Modus zutrifft, und angemessen zu reagieren — als Fachleute und als Organisationen.

Das Verständnis von Software-Entwicklung als Designdisziplin hilft hier: Designarbeit oszilliert naturgemäß zwischen der Anwendung bewährter Muster und der Erfindung neuer Ansätze. Und zu erkennen, was Entwickler intrinsisch motiviert — Stolz auf das Handwerk, Neugier, die Zufriedenheit, echte Probleme zu lösen — hilft Organisationen, Bedingungen zu schaffen, in denen beide Arbeitsmodi gedeihen können.