An mangelnder Fluktuation kann es nicht liegen, denn die Softwareindustrie hat laut einer LinkedIn-Studie 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.
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 in einer Firma wirklich ankommen, soziale Beziehungen aufzubauen 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? Dies 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. Anstelle in die Fortbildung der Mitarbeiter zu investieren, werden also lieber Massagen, Fitnessclub-Mitgliedschaften, 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 nachzutun .
Aber egal wie hoch sie ist, die Fluktuation alleine 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 . 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 . Er zieht daraus eine interessante Schlussfolgerung: aufgrund dieses Wachstums hat dauerhaft jeder zweite Programmierer weniger als fünf Jahre Berufserfahrung.
Schnelles Wachstum
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 haben scheinen, ist es heute nicht ungewöhnlich, eine eigene Entwicklungsabteilung vorzufinden. Sehen wir uns einmal an, wie heute beispielsweise PHP-Entwickler gesucht werden, indem wir uns willkürlich einige Stellenanzeigen ansehen, die auf entwickler.de veröffentlicht sind.
Hier werden beispielsweise Mitarbeiter gesucht, welche 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 , Second-Level-Support von bestehenden Applikationen oder der Pflege und Weiterentwicklung von Software? Wem Bugfixing und Softwaretests nicht zusagt, 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 hier Wartung vorhandener Anwendungen zu entdecken. Und dies, 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: jeder sucht 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 Katalysator-Entwicklungsingenieur von Volkswagen für Pannenhilfe nachts am Straßenrand qualifiziert ist.
Software-Entwicklung ist eine junge Disziplin, deutlich jünger als 100 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 Elektronenrechnen 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 8000 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, das auch heute noch die meisten Software-Projekte (zumindest teilweise) scheitern .
Die Software-Krise
Im Jahr 1968 fand sich eine Gruppe von Experten in Garmisch-Partenkirchen zu einer von der NATO gesponserten Konferenz ein, um der „Software-Krise“ 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 tatsächlich schon sein würden!
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 verselbststä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.
Der „Code“ ist es, was der Informatik den Touch einer Geheimwissenschaft gibt. Wenige ausgesuchte Technologie-Experten schaffen hinter verschlossen Türen Black Boxes, 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 Bus-Faktor ein ernstzunehmendes Risiko für ein Projekt ist. Den Bus-Faktor eines Projektes 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 vorneherein so schreiben, dass sie selbsterklärend sind? Martin Fowler sagte einmal:
Jeder Dummkopf kann Code schreiben, den ein Computer verstehen kann. Gute Programmierer schreiben Code, den Menschen verstehen können.
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, dann 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 gerne mit neuen Technologien und aktuellen Buzzwords gearbeitet wird und 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 alle 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.
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 machen möchte“. Nach meiner Erfahrung stimmt dies 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 klarkommen.
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 unserer Branche gar nicht mehr so begründet.
Unternehmen sollten mehr Mut beweisen und 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 und signalführende 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 zeitweise genau solche Kabelschächte gegeben haben soll.
Was würde unser Elektriker tun? Anstelle mühsam durch Reverse Engineering herauszufinden, was wohin verbunden ist und welchem Zweck es dient, würde er sich auf nicht eingehaltene Branchenstandards berufen, erst einmal alle Leitungen abzwicken und sauber neu verlegen.