Entwickler, nicht Ingenieur. Und warum das wichtig ist

8 Min. Lesezeit

Die erfolgreichste Markenkampagne der Technologiebranche

Ein Begriff, der wehtun sollte

1968 organisierte Professor Friedrich Bauer eine NATO-Konferenz in Garmisch. Er wählte “Software Engineering” als Titel. Brian Randell, einer der Teilnehmer, bestätigte später, die Wortwahl sei “bewusst provokant” gewesen. Die Softwarebranche ertrank in gescheiterten Projekten, gesprengten Budgets und Systemen, die nicht funktionierten. Es “Engineering” zu nennen war eine Aufforderung: Fangt an, euch wie Ingenieure zu verhalten. Wendet Disziplin an. Befolgt Prozesse. Baut Dinge, die nicht zusammenbrechen.

Margaret Hamilton verwendete denselben Begriff bei der NASA während des Apollo-Programms. Sie meinte es wörtlich. Ihr Team baute Flugsoftware, bei der Fehler Astronauten töteten. Die Strenge war real. Das Testen erschöpfend. Die Standards waren dokumentiert und wurden eingehalten. Das war echte Ingenieursarbeit, angewandt auf Software.

Das Problem ist, was danach passierte. Der Anspruch wurde für die große Mehrheit der Branche nie Realität. Wir übernahmen den Titel und übersprangen die Disziplin. Dijkstra erkannte das klar. Er beobachtete, wie Data General über Nacht alle Programmierer zu “Software Engineers” beförderte und nannte das ganze Feld “The Doomed Discipline” (die zum Scheitern verurteilte Disziplin), weil es “sein Ziel nicht einmal annähernd erreichen kann, da sein Ziel in sich widersprüchlich ist.”

Er schrieb das 1988. Geändert hat sich nichts.

Was Ingenieure tatsächlich tun

Ein Bauingenieur berechnet Tragfähigkeiten mit Formeln, die seit Jahrhunderten validiert sind. Ein Elektroingenieur entwirft Schaltkreise gegen bekannte physikalische Grenzen. Ein Maschinenbauingenieur spezifiziert Materialien mit dokumentierten Belastungsgrenzen. Das sind Fachleute, die bekannte Standards auf bekannte Probleme anwenden. Die Physik ist geklärt. Die Mathematik bewiesen. Die Bauvorschriften existieren, weil Menschen starben, bis man sie aufschrieb.

Wenn eine Brücke versagt, wird untersucht. Wenn sie versagt, weil der Ingenieur etablierte Standards ignoriert hat, wird die Zulassung entzogen. Es gibt Verantwortlichkeit. Es gibt ein Wissensgebiet mit klaren Grenzen. Es gibt ein professionelles Zulassungsverfahren mit Prüfungen, Ausbildungszeiten, Weiterbildungspflicht und rechtlichen Konsequenzen bei Pflichtverletzung.

Software hat nichts davon. In den USA wurde 2013 eine Ingenieurprüfung für Software eingeführt. 2019 wurde sie eingestellt. Nicht genügend Teilnehmer. Die ACM und IEEE prüften die Idee einer Lizenzierung von Software-Fachleuten und kamen zum Schluss, dass “the framework of a licensed professional engineer, originally developed for civil engineers, does not match the professional industrial practice of software engineering.”

Lesen Sie den Satz noch einmal. Die zwei größten Berufsverbände der Informatik weltweit sagten: Was wir tun, passt nicht zu dem, was Ingenieure tun. Und dann verwendeten alle den Titel trotzdem weiter.

Die kalifornische Ausnahme, die die Welt eroberte

In Teilen Kanadas ist es illegal, sich ohne Akkreditierung Ingenieur zu nennen. In mehreren europäischen Ländern ist der Titel reguliert. In Deutschland ist “Ingenieur” ein geschützter Titel, der an ein entsprechendes Studium gebunden ist. Wer sich ohne passenden Abschluss so nennt, verstößt gegen das Ingenieurgesetz des jeweiligen Bundeslandes.

Kalifornien kümmert das nicht. Und dort nimmt die globale Software-Branche ihre kulturellen Impulse her.

Das Silicon Valley machte “Engineer” zum Standardtitel für jeden, der Code schreibt. Ian Bogost brachte es 2015 im Atlantic auf den Punkt: “In the Silicon Valley technology scene, it’s common to use the bare term ‘engineer’ to describe technical workers. Somehow, everybody who isn’t in sales, marketing, or design became an engineer.”

Warum? Mehrere Gründe, keiner davon hat mit tatsächlicher Ingenieursarbeit zu tun:

Prestige. “Software Engineer” klingt auf der Visitenkarte besser als “Programmierer.” Ein Akademiker formulierte es so: “If you are a programmer, you might put ‘software engineer’ on your business card, never ‘programmer’ though.” Gleiche Arbeit. Bessere Marke.

Recruiting. Startups, die um Talente in einem engen Arbeitsmarkt konkurrierten, stellten fest, dass “Engineer” mehr Bewerbungen anzieht als “Developer.” Der Titel wurde zum Einstellungsinstrument, nicht zur Beschreibung der Tätigkeit.

Vergütungsstrukturen. Stellenbezeichnungen beeinflussen Gehaltsbänder. “Engineer” rutscht in den Personalsystemen in höhere Vergütungsstufen als “Developer” oder “Programmer.” Der Titel bringt einen Gehaltsaufschlag, der nichts mit Strenge oder Disziplin zu tun hat.

Niemand, der Stopp sagt. Im Gegensatz zu Bau- oder Maschinenbauingenieuren gibt es keine Zulassungsbehörde, keine Akkreditierungsstelle, keinen rechtlichen Rahmen, der ein Unternehmen daran hindert, jeden Programmierer Ingenieur zu nennen. Also tun sie es. Denn warum nicht, wenn der Titel nichts kostet und mehr Gehalt bringt?

Googles eigenes Buch, “Software Engineering at Google,” versuchte den Begriff komplett umzudefinieren: Software-Entwicklung sei “programming integrated over time.” Ein interessanter Gedanke. Aber gleichzeitig das Eingeständnis, dass das Wort “Engineering” so weit gedehnt wird, bis es etwas völlig anderes bedeutet als das, was der Rest der Ingenieursberufe darunter versteht.

Warum die Unterscheidung wirklich wichtig ist

Das ist keine Wortklauberei. Die Bezeichnung formt Erwartungen. Und falsche Erwartungen töten Projekte.

Wenn Sie einer Geschäftsführung sagen, dass Sie “sechzig Software Engineers” haben, hört sie “sechzig Fachleute, die bekannte Standards anwenden, um planbare Ergebnisse zu liefern.” Sie erwartet Gantt-Diagramm-Genauigkeit. Sie erwartet, dass mehr Entwickler schnellere Auslieferung bedeuten. Sie erwartet die Art linearer Planbarkeit, die beim Bau einer Lagerhalle funktioniert, aber bei der Software-Entwicklung nie funktioniert hat.

Software-Entwicklung ist manchmal Handwerk und manchmal Gewerbe, aber selten Ingenieursarbeit im traditionellen Sinn. Ein Handwerker installiert eine Küche nach etablierten Mustern. Ein Kunsthandwerker entwirft und baut ein Einzelstück. Ein Ingenieur berechnet Belastungsgrenzen für eine Brücke. Ein Entwickler? Ein Entwickler findet heraus, was er bauen soll, während er es baut. Anforderungen ändern sich mittendrin. Nutzer wissen nicht, was sie wollen. Die Technologie verschiebt sich unter den Füßen. Das ist Schaffen unter Unsicherheit, nicht Anwendung bekannter Standards.

Die Bezeichnung “Engineering” füttert die Illusion, dass Management-Frameworks die gleiche Planbarkeit liefern können wie beim Bau. Deshalb planen Unternehmen immer noch Sechsmonatsprojekte mit festem Zeitrahmen, besetzen Stellen nach Plan statt den Plan an die Realität anzupassen, und sind schockiert, wenn der Zeitplan kippt. Brücken machen kein Pivot. Software schon. Oder sollte es.

Elektriker haben eine Autorität, die Entwickler nicht haben, und ein Teil des Grundes ist, dass Elektriker nicht vorgeben, etwas zu sein, das sie nicht sind. Sie haben einen klaren Zuständigkeitsbereich, regulierte Kompetenz und die Macht, Nein zu sagen, gestützt auf Vorschriften. Software-Entwickler haben sich einen prestigeträchtigen Titel geliehen, ohne die Infrastruktur der Verantwortlichkeit, die ihn bedeutsam macht.

Was wir tatsächlich sind

Software-Entwicklung ist eine kreative, iterative Disziplin, die unter radikaler Unsicherheit stattfindet. Die Anforderungen sind unvollständig. Die Werkzeuge entwickeln sich ständig weiter. Der Lösungsraum wird nicht durch Physik begrenzt. Zwei Entwickler, die dasselbe Problem lösen, werden grundlegend unterschiedliche Lösungen produzieren, die beide funktionieren können. Bei Brückenberechnungen passiert das nie.

Das macht Software-Entwicklung nicht weniger wert als Ingenieursarbeit. Es macht sie anders. Eine andere Disziplin mit anderen Randbedingungen, die andere Führungsansätze erfordert. Sie als Engineering zu behandeln ist kein Kompliment. Es ist ein Missverständnis, das zu schlechten Entscheidungen führt.

Entwickler mit Respekt zu behandeln beginnt damit, sie das zu nennen, was sie sind. Nicht weil “Entwickler” ein hübscheres Wort ist, sondern weil Genauigkeit in der Sprache Genauigkeit in den Erwartungen erzeugt. Wenn Sie verstehen, dass Software-Entwicklung kreative Arbeit unter Unsicherheit ist, hören Sie auf, feste Schätzungen für neuartige Probleme zu verlangen. Sie hören auf, Produktivität in Codezeilen zu messen. Sie hören auf anzunehmen, dass mehr Leute die Dinge schneller machen.

Die besten Software-Teams, mit denen ich gearbeitet habe, nennen sich nicht Ingenieure. Sie nennen sich Entwickler oder einfach das Team. Sie konzentrieren sich auf technische Praktiken, die tatsächlich Ergebnisse liefern: testgetriebene Entwicklung, Continuous Integration, Trunk-based Development, ausführbare Spezifikationen. Das sind Disziplinen, ja. Aber es sind Disziplinen des Handwerks und der Entdeckung, nicht der angewandten Physik.

Der Titel wird sich nicht ändern. Das Denken sollte es

Das Silicon Valley hat diesen Namensstreit vor Jahrzehnten gewonnen. “Software Engineer” steckt in Stellenausschreibungen, Vergütungsstrukturen, Visa-Anträgen und LinkedIn-Profilen weltweit. Niemand wird die Branche umbenennen.

Aber das Denken hinter dem Titel kann sich ändern. Führungskräfte, die den Unterschied zwischen Ingenieursarbeit und Entwicklung verstehen, treffen bessere Entscheidungen über Zeitpläne, Budgets und Teamstrukturen. Sie hören auf, Fabrikplanbarkeit von kreativer Arbeit zu erwarten. Sie beginnen, in technische Kompetenz statt in Framework-Übernahme zu investieren.

Nennen Sie sich, wie das Personalsystem es verlangt. Schreiben Sie “Engineer” auf Ihr LinkedIn-Profil, wenn es Sie am Keyword-Filter des Recruiters vorbeibringt. Aber wenn Sie in einer Planungssitzung sitzen und jemand fragt, warum das Projekt nicht wie ein Bauprojekt geplant werden kann, kennen Sie die Antwort.

Weil Sie kein Ingenieur sind. Sie sind etwas anderes. Etwas, das schwerer zu führen, schwerer vorherzusagen und in vielerlei Hinsicht schwerer gut zu machen ist. Sie sind Entwickler. Und das ist kein Trostpreis. Es ist eine ehrlichere Beschreibung einer komplexeren Realität.