Die Legende vom "Fullstackicorn"

Darum ist Full-Stack-Engineering schädlich

Kommentar von Jeremy Duvall

Full-Stack-Engineering klingt traumhaft. In der Realität ist es leider ein Garant für langsamere Entwicklung, minderwertige Software, technische Schulden – und überforderte Developer.

Die Legende vom "Fullstackicorn": Lesen Sie, warum der Einsatz von Full-Stack-Solisten nur in sehr begrenztem Umfang gut endet. Und wie es besser geht.
Foto: NSTIvectors - shutterstock.com

Es ist eine Vorstellung, die verzaubert: Der Entwickler, der einfach alles kann, jede Disziplin seines Handwerks beherrscht - das magische "Fullstackicorn".

Stellen Sie für Ihr Startup oder Tech-Unternehmen ein? Ein Full-Stack-Entwickler leistet doppelt so viel wie ein regulärer Developer.
Starten Sie gerade Ihre Karriere als Softwareentwickler oder wollen auf der Karriereleiter aufsteigen? Mit Full-Stack-Engineering bringen Sie es doppelt so schnell zu einer Führungsposition.

Full-Stack-Engineering ist wirklich attraktiv. Allerdings nur auf dem Papier. In der Realität handelt es sich um einen Mythos, der in vielen Fällen einen faulen Kompromiss darstellt, der zu einem qualitativ minderwertigen Produkt führen kann. Der "Preis" dafür: Eine Person in der Belegschaft wird massiv überlastet.

Wenn Sie Entwickler sind und am Anfang Ihrer Karriere stehen, sollten Sie sich vor jeder Stellenausschreibung hüten, in der ein Full-Stack-Engineer gesucht wird. Das bedeutet im Regelfall nämlich nur eines: Sie dürfen zwei Jobs für ein Gehalt erledigen.
Wenn Sie Developer einstellen möchten, sollten Sie nicht ausschließlich nach Full-Stack-Entwicklern suchen. Die hierdurch vermeintlich zu erzielenden Einsparungen werden Sie in Form von fehlerhaften Datenbanken, technischen Schulden und unzumutbaren User Journeys einholen.

Natürlich gibt es bei diesem Thema nicht nur schwarz und weiß: Full-Stack-Entwickler können für bestimmte Tools, die auf spezifische Use Cases ausgerichtet sind, perfekt funktionierenden Code liefern (mehr dazu später). Full-Stack-Expertise kann zudem für erfahrene Entwickler eine Art "Endspiel" darstellen.

Wie viel seines versprochenen Wertes Full-Stack-Engineering realisieren kann, ist schwer zu sagen - vielleicht ein Drittel. Das spielt aber auch keine Rolle: Ein leistungsstarkes, erfahrenes Team mit diversen spezialisierten Engineers ist für Unternehmen in jedem Fall deutlich wertvoller. Im Folgenden lesen Sie, warum.

Verstand sucht Multi-Threading

Das menschliche Gehirn hat viele Talente. Exponentiell zu skalieren und Informationen unter hoher kognitiver Belastung parallel zu verarbeiten, gehören nicht dazu. Oft sind es gerade die Menschen, die sich für enorm multitasking-fähig halten, die sich in ebendieser Disziplin als unfähig erweisen. Full-Stack-Engineering ist unterdessen nur eine Worthülse, die verdecken soll, dass es sich um eine Tätigkeit handelt, bei der der Kontextwechsel zur chronischen Krankheit wird. In der Praxis könnte das folgendermaßen aussehen:

Während Sie ein Boyce-Codd-Datenbankschema entwerfen und es in einen hochskalierbaren RESTful-Call implementieren,
erstellen Sie parallel ein intuitives User Interface, das Interaktionen mit den korrespondierenden Object Models anzeigt.
Anschließend supporten und warten Sie die komplette Implementierung - inklusive des zu lösenden Problems.
Klingt nach einem entspannten Tag, finden Sie nicht?

In meiner Welt stellen Front-End- und Back-End-Engineering gleichermaßen komplexe Disziplinen dar - die jeweils ihre eigenen Prioritäten und Methoden aufweisen. Die Grundlagen beider Disziplinen sicher zu beherrschen, nimmt viele Jahre in Anspruch und weil sie sich immer weiterentwickeln, ist der Lernprozess nicht endlich, sondern fortlaufend.

Full-Stack-Engineering verlangt den Menschen zu viel auf einmal ab. Eine solche kognitive Belastung strapaziert die Kapazität unseres Gehirns unnötig. Diese Überlastung kann die Entwicklungsprozesse verlangsamen und damit in der Folge in massive technische Schulden münden. Und das betrifft nicht nur unerfahrene Entwickler: Weil die Evolution in Front-End- und Back-End-Entwicklung so schnell voranschreitet haben selbst abgehärtete und erfahrene Developer Mühe, Schritt zu halten.

Es mag "heldenhaft" erscheinen, sich als Entwickler einer solchen Herausforderung zu stellen. Letztlich sind die Chancen auf Erfolg aber größer, wenn die Herausforderungen auf ein Team verteilt werden, das gemeinschaftlich eine Lösung erarbeitet. Unsere Grenzen anzuerkennen, führt in diesem Fall zu besseren Ergebnissen.

10 Dinge, die Software-Entwickler austicken lassen

Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen."

Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an.

Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen."

Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht."

Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich.

Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon."

Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis.

Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox.

Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an."

Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."

Im Land der "Fullstackicorns"

Es gibt tatsächlich einen kleinen, abgegrenzten Bereich, in dem der Einsatz eines "Fullstackicorns" Sinn machen kann. Wie bereits erwähnt, kann effizientes Full-Stack-Engineering für ehrgeizige Senior Developer ein erreichbares Ziel darstellen (auch wenn diese Entwickler in der Regel als Bestandteil eines Teams im oben genannten Sinne deutlich mehr Wert realisieren).

Ein Full-Stack-Entwickler kann für spezifische Entwicklungsprobleme im Alleingang brauchbare Lösungen entwickeln. Dafür gibt es zwei Use Cases:

Server-seitig gerenderte Monolithen und
eilig zusammengestöpselte Minimum Viable Products (MVPs) oder Prototypen (manchmal ein Spezialfall des Erstgenannten).

Einige Probleme sind gängig und simpel genug, um sie mit Server-seitig gerenderten Monolithen zu lösen. Wenn die benötigte Lösung bequem in die Patterns passt, die Frameworks wie Ruby on Rails, Django oder Laravel bereitstellen, können Full-Stack-Entwickler (die mit diesen Frameworks vertraut sind), eine effiziente Lösung erstellen. Dabei sollten Sie nicht vergessen, dass ein Monolith zwar kurzfristige Bedürfnisse erfüllen kann - aber Grenzen in Sachen Komplexität und Skalierbarkeit setzt. Sie legen sich damit also auf spezifische und limitierte Optionen fest, die für eine Reihe bekannter Probleme entwickelt wurden. Es ist durchaus möglich, dass Sie Ihre Codebasis später neu aufbauen müssen, um auf richtig dimensionierte Services umzusteigen oder einen innovativeren Ansatz für ein neuartiges Problem zu implementieren.

In ähnlicher Weise begnügen sich vor allem Startups in der Anfangsphase manchmal damit, ein "unverbindliches" MVP zu erstellen, während sie sich um die Finanzierung bemühen. Diese Aufgabe können Full-Stack-Engineers übernehmen, allerdings sollte dabei mit offenen Karten gespielt und kein unnötiger Druck aufgebaut werden, nur weil das Startup es sich nicht leisten kann, ein größeres Team einzustellen. Das Wichtigste dabei aus Entwicklersicht: Sie müssen sich darüber bewusst sein, dass Sie den Code möglicherweise von Grund auf neu konzipieren müssen, wenn die Finanzierung steht. Ein unzureichendes MVP zu überarbeiten oder zu erweitern ist nicht realistisch: Sehr wahrscheinlich (beziehungsweise hoffentlich) wird dieses verworfen und anschließend mit einem qualifizierten Team neu aufgebaut.

Wenn sich alle Beteiligten über die Einschränkungen und Konsequenzen klar sind und Einigkeit darüber besteht, diese eingehen zu wollen, können Sie das "Fullstackicorn" entfesseln. Wenn das nicht der Fall ist, gibt es einen anderen Weg, der Sie zur Lösung führen kann.

Full-Venn-Engineering Teams

Dieser besteht darin, ein kollaboratives Team aus Front-End- und Back-Ed-Entwicklern zusammenzustellen. Das dürfte weitaus effektiver funktionieren als ein Full-Stack-Solist:

Back-End-Entwickler können sich auf den Data Layer, gut designte RESTful-Endpunkte, Threading, Skalierbarkeitsprobleme oder die Vermeidung des n+1-Problems bei Abfragen fokussieren.
Front-End-Developer können sich auf angenehme, intuitive Interaktionen zwischen Benutzer und Anwendung, effiziente UI-Bundle-Downloads und gut gestaltete, wiederverwendbare Komponenten konzentrieren.

Einen Großteil ihrer Arbeit können Front-End- und Back-End-Entwickler alleine erledigen und sich dabei voll und ganz auf ihr Spezialgebiet konzentrieren. Dort, wo sich die Aufgabenbereiche (beziehungsweise die Kreise in einem Venn-Diagramm) überschneiden, arbeiten die Mitglieder des Teams jedoch zusammen, um die beste Lösung zu finden. Dazu könnte beispielsweise gehören, sich über folgende Fragestellungen abzustimmen:

Auf welche Daten müssen die Benutzer wie zugreifen?
Wie wird die Benutzeroberfläche die API aufrufen?
Wie sieht der Datenvertrag aus?

Anschließend kümmern sich die jeweiligen Entwickler um ihren Teil der Lösung. Indem Sie das Team zusammenbringen, verlangsamen Sie den Entwicklungsprozess zwar kurzzeitig. Dafür verfügen die Developer aber anschließend über den erforderlichen Kontext, um schneller voranzukommen und die Funktionen in ihren jeweiligen Silos korrekt zu implementieren. Angesichts der funktionalen Überschneidungen ist dabei auch wichtig, dass jedes Teammitglied ein gewisses Verständnis vom Fachgebiet des anderen hat. Das muss - besonders bei Entwicklern, die am Anfang ihrer Karriere stehen - nicht besonders tiefgehend sein.

Kollaborative Karriereentwicklung

Softwareentwickler, die am Anfang ihrer Karriere stehen, tendieren dazu, alles auf einmal lernen zu wollen. Diese Ungeduld kann den Lernfortschritt allerdings hemmen.

Ein Beispiel: Stellen Sie sich vor, Sie wollen gleichzeitig einen Doktortitel in Mathematik und Biologie erwerben, um wichtige Probleme der Proteinfaltung anzugehen. Wenn Sie Ihre Aufmerksamkeit und Zeit auf beide Bereiche aufteilen, wird es viele Jahre dauern, bis Sie ihren Titel in der Tasche haben. Noch viel länger wird es in Anspruch nehmen, auf diesen Gebieten einen bedeutenden Beitrag zu leisten - beziehungsweise leisten zu können, bevor jemand anderes das getan hat oder eine Entwicklung dafür gesorgt hat, dass das Problem nicht mehr besteht.

Der klügere Weg: Konzentrieren Sie sich auf ein Gebiet. Angenommen, das wäre die Mathematik, könnten sie sich zum Beispiel auf statistische Mechanik spezialisieren. Auf Ihrem Weg werden Sie Kontakte zu Kollegen aus der Molekular- und Zellbiologie knüpfen, Allianzen bilden und interdisziplinäre Teams bilden. Auf diesem Weg bringen Sie Ihr mathematisches Verständnis voran, haben parallel aber auch die Möglichkeit, von Kollegen zu lernen. Dieses Wissen reicht dann vielleicht nicht zum Doktortitel, aber dafür, um gemeinsam an interessanten Problemstellungen zu arbeiten. Dabei lernen Sie auch, wie gute Zusammenarbeit funktioniert.

Dieses Vorgehen verschafft Ihnen einen Vorteil in Ihrer Karriere und in Ihrer Fähigkeit, auf Ihrem Gebiet etwas bewirken zu können - und ist übertragbar auf das Feld der Softwareentwicklung: Sie werden schneller vorankommen und mehr erreichen, wenn Sie sich für eine gewisse Zeit entweder auf Front-End- oder Back-End-Engineering konzentrieren und dann lernen, gut in einem cross-funktionalen Team zusammenzuarbeiten.

Am Ende eine solchen, eben skizzierten Karrierewegs sind Sie wesentlich mehr als ein "ordinärer" Full-Stack-Entwickler: Sie beherrschen die Grundlagen, verfügen über Spezialwissen auf ihrem Fachgebiet und bringen darüber hinaus Knowhow in angrenzenden Fachgebieten und Collaboration mit. Das sind die besten Voraussetzungen für eine erfolgreiche Entwicklerkarriere. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.