Wer sucht heute keine Entwickler? Der Arbeitsmarkt, speziell für PHP-Entwickler, ist schon seit Jahren so gut wie leergefegt. Fast jedes Unternehmen sucht mehr oder weniger händeringend Softwareentwickler. Und fast jedes Unternehmen fragt sich, was man tun muss, um mehr oder bessere Kandidaten zu finden.

An mangelnder Fluktuation kann es nicht liegen, denn die Softwareindustrie hat laut einer LinkedIn-Studie [1] die höchste Fluktuationsrate aller Branchen. Große Firmen wie Google oder Amazon schaffen es heute im Mittel gerade einmal, die Mitarbeiter für rund ein Jahr zu halten [2]. Manager aus dem Silicon Valley berichten, dass die untere Grenze für die Verweildauer von Entwicklern mittlerweile bei rund sechs Monaten liegt. Sechs Monate! Das ist aus verschiedenen Gründen erschreckend, denn die Mitarbeiter müssen ja praktisch direkt nach dem Einstand damit beginnen, ihren Ausstand zu planen. Im Ernst: Wie soll man in so kurzer Zeit wirklich in einer Firma ankommen, soziale Beziehungen aufbauen und Vertrauen schaffen? Kann man in so kurzer Zeit jemals einen wirklich wertvollen Beitrag zum Unternehmensgeschehen leisten?

Und warum sollte das Unternehmen den Mitarbeiter auf eine Konferenz oder in eine Schulung schicken? Das würde ja nur den Marktwert des Mitarbeiters erhöhen, und der würde dann womöglich für ein höheres Gehalt direkt zur Konkurrenz wechseln. Anstatt in die Fortbildung der Mitarbeiter zu investieren, werden also lieber Massagen, Fitnessclubmitgliedschaften, Snacks und Getränke angeboten. In Deutschland ist die Fluktuation glücklicherweise (noch) nicht so hoch, auch wenn Städte wie Berlin auf dem besten Weg scheinen, es dem Silicon Valley nachzumachen.

Aber egal wie hoch sie ist, die Fluktuation allein reicht nicht aus, das Problem der knappen Entwickler zu lösen, denn sie ist nur eine Umverteilung. Die Branche wächst seit Jahrzehnten mehr oder weniger ungebremst, sogar schneller als die Gesamtwirtschaft [3]. Robert „Uncle Bob“ Martin hat aufgezeigt, dass die Softwareindustrie eine Wachstumsrate hat, bei der sich die Anzahl von Programmierern etwa alle fünf Jahre verdoppelt [4]. Er zieht daraus eine interessante Schlussfolgerung: Aufgrund dieses Wachstums hat dauerhaft jeder zweite Programmierer weniger als fünf Jahre Berufserfahrung.

Warum Instandhaltung immer wieder unterschätzt wird

In Zeiten von Automation und Digitalisierung sind die meisten Geschäftsmodelle auf eine schnelle Skalierbarkeit von Unternehmen ausgelegt; dies gilt natürlich ganz besonders, wenn digitale Güter hergestellt oder vertrieben werden. Gerade hier werden zunehmend Entwickler gebraucht, aber selbst in kleinen und mittelständischen Unternehmen, die primär überhaupt nichts mit IT zu tun zu haben scheinen, ist es heute nicht ungewöhnlich, eine eigene Entwicklungsabteilung vorzufinden. Sehen wir uns einmal an, wie heute PHP-Entwickler gesucht werden, indem wir uns willkürlich einige Stellenanzeigen ansehen, die auf www.entwickler.de veröffentlicht sind.

Hier werden beispielsweise Mitarbeiter gesucht, die die „Betreuung und Weiterentwicklung unserer Webportale und weiterer Anwendungen“ übernehmen, oder an „hoch skalierbaren und in einer Cloud-basierten Infrastruktur gehosteten PHP 7-Produkten“ arbeiten. Wie wäre es mit „Inbetriebnahme und Customizing unserer Produkte bei Kunden“, „2nd-Level-Support von bestehenden Applikationen“ oder der „Pflege und Weiterentwicklung“ von Software? Wem „Bugfixing und Softwaretests“ nicht zusagen, der findet vielleicht sein Glück beim Vorantreiben der „bestehenden internationalen B2B-Kundenprojekte“.

Man muss nicht einmal zwischen den Zeilen oder im Kleingedruckten lesen, um „Wartung vorhandener Anwendungen“ zu entdecken. Und das, obwohl Programmierer, Developer, IT Engineers, Softwareentwickler oder auch „Webentwickler Backend“ gesucht werden. Wenn ein großer Anteil der Tätigkeit die Wartung vorhandener Software ist, warum sucht man dann Entwickler und nicht einen Maintainer? Ich kenne Fälle, in denen die Stellenanzeige den Einsatz modernster Technologien und Arbeitstechniken anpries, nur um den neu eingestellten Entwickler dann ausschließlich Bugfix-Tickets im Legacy-System abarbeiten zu lassen. Woher kommt es eigentlich, dass bei den Stellenbeschreibungen niemand einen Unterschied zwischen Entwicklung und Wartung macht?

In vielen Industriezweigen gibt es – im Gegensatz zur Softwarebranche – übrigens eine sehr deutliche Trennung zwischen Entwicklung und Wartung. Ein Ingenieur bei Airbus beispielsweise konstruiert Flugzeuge. Ein Ingenieur bei Lufthansa ist dagegen für die Wartung von Flugzeugen im laufenden Betrieb verantwortlich. Beide Tätigkeiten sind wichtig, haben aber ein völlig unterschiedliches Anforderungsprofil. Wer würde auf die Idee kommen, den gleichen Ingenieur für beide Tätigkeiten einzusetzen? Beim Software-„Entwickler“ scheint niemand ein Problem darin zu sehen, eine Person beide Aufgaben jonglieren zu lassen.

Dabei ist die Wartung von Software für den laufenden Geschäftsbetrieb essenziell, möglicherweise sogar wichtiger als die Entwicklung von neuen Funktionalitäten. Vorhandene Lösungen müssen schließlich an Gesetzesänderungen oder einen veränderten Markt angepasst werden, ansonsten ist für das Unternehmen mitunter schon nach kurzer Zeit keine wirtschaftlich sinnvolle Wertschöpfung mehr möglich. Dennoch sucht jeder Entwickler, aber niemand sucht Maintainer, also Instandhalter. Dabei gibt es zahlreiche Industriezweige, die nur auf Instandhaltung basieren. Ein KFZ-Mechaniker beispielsweise ist für Wartung und Instandhaltung von vorhandenen Fahrzeugen zuständig. Ein Hausmeister sorgt für reibungslose Operations einer Immobilie. Niemand würde auf die Idee kommen, den Hausmeister mit dem Bau einer neuen Immobilie zu beauftragen. Und für den Bau eines neuen Fahrzeugs from scratch wäre der durchschnittliche KFZ-Mechaniker vermutlich genauso wenig geeignet, wie ein Katalysatorentwicklungsingenieur von Volkswagen für Pannenhilfe nachts am Straßenrand qualifiziert ist.

Softwareentwicklung ist eine junge Disziplin, deutlich jünger als hundert Jahre. Wenn man von den sehr frühen Anfängen bei Charles Babbage und Ada Lovelace absieht, dann entstand das Berufsbild des Programmierers mit der Entstehung von Elektronenrechnern im Zuge des zweiten Weltkrieges. Kein Wunder, dass wir im Vergleich mit anderen Industrie- und Berufszweigen nur wenig Erfahrung haben. Die Menschheit baut beispielsweise seit rund 8 000 Jahren Häuser. Eine Menge Zeit, um vielfältige Erfahrungen zu sammeln. Dennoch war es noch vor wenigen hundert Jahren nicht besonders überraschend, wenn eine im Bau befindliche Kathedrale in Teilen einstürzte und neu gebaut werden musste. Vor diesem Hintergrund verwundert es dann nicht mehr so sehr, dass auch heute noch die meisten Softwareprojekte (zumindest teilweise) scheitern. Laut Chaos-Studie [5] wurden in 2015 nur 30 Prozent der Softwareprojekte im geplanten Zeitraum unter Einhaltung des Budgets und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen.

Im Jahr 1968 fand sich eine Gruppe von Experten in Garmisch-Partenkirchen zu einer von der NATO gesponserten Konferenz ein, um der Softwarekrise zu begegnen. Schon damals hatte man erkannt, dass die Skalierung der Programmierer ein größeres Problem war als die Skalierung der Rechner selbst. Edsger Dijkstra sagte 1972: „Solange es keine Maschinen gab, war Programmierung kein existierendes Problem; als wir ein paar schwache Computer hatten, wurde Programmierung zu einem geringen Problem, und nun, da wir gigantische Computer haben, ist die Programmierung ein ebenso gigantisches Problem.“ Wenn Dijkstra damals auch nur geahnt hätte, wie leistungsfähig Rechner nur wenige Jahrzehnte später tatsächlich schon sein würden!

Die Glorifizierung der „Geheimwissenschaft“

Interessant ist, dass in der Anfangszeit der Informatik noch zwischen dem Programmierer und dem Kodierer unterschieden wurde. Der Programmierer war ein Fachanwender, der einen Algorithmus entwickelte und von Hand aufschrieb. Der Kodierer war dann derjenige, der das Programm in Lochstreifen kodierte und auf dem Computer zur Ausführung brachte. Noch heute bezeichnen wir Programmierer umgangssprachlich als Coder, obwohl sich das Berufsbild des Programmierers schon längst vom Fachanwender weg verselbständigt hat. Die Bezeichnung Code an sich ist höchst problematisch, denn Code ist etwas, das geheimnisvoll, obfuskiert und schwer zu lesen ist. Entwickler sollten keinen Code schreiben [6]. Der Code ist es, was der Informatik den Touch einer Geheimwissenschaft gibt. Wenige, ausgesuchte Technologieexperten schaffen hinter verschlossen Türen Blackboxes, die normale Menschen nicht verstehen können – oder sollen. Das mag in der Vergangenheit zur Existenzsicherung einzelner Programmierer – oder der zumindest versuchten Glorifizierung einzelner Abteilungen – immer wieder einmal funktioniert haben. Heute aber haben die meisten Firmen erkannt, dass ein niedriger Busfaktor [7] ein ernstzunehmendes Risiko für ein Projekt ist. Den Busfaktor eines Projekts kann man erhöhen, indem man Wissensinseln vermeidet, Komplexität reduziert oder besser dokumentiert. Sollte man nun unlesbare Programme (Code) durch Dokumentation erklären, oder die Programme von vornherein so schreiben, dass sie selbsterklärend sind? Martin Fowler sagte einmal: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.“

Die meisten Entwickler würden vermutlich sagen, dass ihnen im Unternehmen nicht genügend Spielraum gegeben wird, um gute, also lesbare Software zu entwickeln. Fakt ist aber auch, dass es vielen Entwicklern im ersten Wurf meist noch nicht gut genug gelingt, qualitativ hochwertige Software zu schreiben. Erst durch rigoroses und zielgerichtetes Refactoring entsteht die gewünschte Lesbarkeit. In der Tat werden aber Programme, wenn sie erst einmal in Produktion sind, häufig nur noch wenig geändert; meist, weil zu wenig Testautomation vorhanden ist und der manuelle Testaufwand zu hoch wäre. Über die Frage, ob dies nun ein Versäumnis der Entwickler oder des Unternehmens ist, soll an anderer Stelle diskutiert werden.

Ein Elektriker, der eine Hausinstallation macht, wird sich an eine standardisierte Farbcodierung der Leitungen halten, sodass jeder andere Fachmann, der später an dieser Anlage arbeitet, sofort weiß, welche Leitungen Strom führen und welche beispielsweise als Erdung am Gehäuse anzuschließen sind. Dass jeder Elektriker, dem sein eigenes Leben und das Leben der Kunden lieb ist, trotzdem nochmal nachmisst, bleibt natürlich unbenommen. In der Informatik können wir die Ergebnisse solcher Messungen – man könnte sie auch Dokumentation nennen – übrigens in Form von automatisierten Tests direkt dem Projekt beilegen, sodass diejenigen, die nach uns kommen, nicht nur auf Knopfdruck eine Dokumentation erhalten, sondern sich auch sicher sein können, dass diese mit dem vorhandenen Computerprogramm übereinstimmt.

Wenn es uns als Entwickler nicht gelingt, nachhaltige Software zu schreiben, deren Wartung nicht nur risikoarm ist, sondern vielleicht sogar Spaß macht, werden wir dann von Unternehmen damit bestraft, eben diese Software in den nächsten Jahren zu warten? Selbst wenn dem so wäre, würde diese Rechnung nicht aufgehen. Das nächste Jobangebot ist schließlich nur einen Mausklick weit entfernt. Aber was erwartet einen da – Entwicklung oder Wartung?

Es scheint, dass in vielen Stellenanzeigen gern mit neuen Technologien und aktuellen Buzzwords gearbeitet wird, dann aber doch ein Anteil von über 50 Prozent der Arbeitszeit für die Wartung vorhandener Systeme verwendet werden soll. Im besten Fall führt dies zu Unzufriedenheit, weil der Mitarbeiter all diese tollen Technologien nicht in die Legacy-Software einführen darf; im schlimmsten Fall führt es dazu, dass der Mitarbeiter genau dies tut und mehr und mehr Komplexität entsteht, die schnell nicht mehr beherrschbar ist. Freilich gibt es Fälle, in denen veraltete Technologien ersetzt werden müssen. Der Treiber dafür ist aber die veraltete Technologie und nicht das Vorhandensein einer neuen, scheinbar viel besseren Alternative.

Warum nicht mal einen Maintainer suchen?

Schlägt man nun einem Unternehmen vor, anstelle eines Entwicklers einen Maintainer für vorhandene Software zu suchen, wird meist reflexartig abgewehrt, „weil das keiner möchte“. Nach meiner Erfahrung stimmt das nicht. Ich kenne viele Entwickler, die in ihrem Gebiet teilweise sehr, sehr gut sind, aber wenig Spaß an der Neuentwicklung von Software haben, weil sie mit den damit verbundenen Unsicherheiten nicht so gut zurechtkommen. Und wie viele Leute haben großen Spaß daran, sich mit Retro-Computing zu beschäftigen oder in Workshops alte Geräte zu reparieren? Möglicherweise ist die Angst, dass Entwickler immer nur neue Dinge machen wollen, mit zunehmendem Alter unser Branche gar nicht mehr so begründet. Unternehmen sollten vielleicht mehr Mut beweisen und tatsächlich einmal Personal explizit für die Wartung von Software und Systemen suchen.

Um allerdings eine wirkliche Veränderung zu bewirken, muss neu entwickelte Software noch wartungsfreundlicher werden, als sie es heute regelmäßig ist. Stellen wir uns vor, ein Elektriker soll Wartungsarbeiten erledigen. Er trifft in einem Haus auf eine nicht nachvollziehbare Vielfalt von verlegten Leitungen in unterschiedlichen Dicken und Farben. Hier liegen stromführende Leitungen mit signalführenden Leitungen kreuz und quer und es ist völlig unklar, welche Adern die Masse, geschweige denn die Schutzerde sind. Anekdotisch wird übrigens hie und da erzählt, dass es auf der Flughafenbaustelle BER teilweise genau solche Kabelschächte geben soll.

Was würde unser Elektriker tun? Anstatt durch Reverse Engineering mühsam herauszufinden, was wohin verbinden ist und welchem Zweck es dient, würde er sich auf nicht eingehaltene Branchenstandards berufen, erst einmal alle Leitungen abzwicken und sauber neu verlegen.