Der aktuelle, traurige Zustand der Software-Entwicklung in Deutschland hat mich schon viele Stunden meines Lebens beschäftigt. In einem Land, das in vielen Bereichen noch immer nach Perfektion, Innovation und Effizienz strebt, ist es eigentlich nicht erklärlich, warum massenhaft auf veraltete Technologien, veraltete Methoden und unflexible Ansätze gesetzt wird.
Hier meine Theorie:
Der Ursprung liegt in den 1990ern beim Beginn des Web-Hypes: Im Zuge der extremen Wachstumsraten und Bewertungen, der unabsehbaren Hoffnungen und Risiken für bestehende Unternehmen wurde aus der Not heraus sehr viel Kapital investiert. Große Konzerne, beeindruckt oder gar existenziell bedroht, investierten Unsummen in neue Technologien, oftmals ohne Versand, um dem Zeitgeist zu genügen.
Man wollte großes bauen, man wollte alles in dieser neuen Sprache names Java bauen, die gerade extrem populär wurde. Eine Sprache, eine Technologie für alles — besser, schneller, skalierender als je zuvor!
Doch dann platzte die Dotcom-Blase und viele Ideen und Konzepte stellten sich als nicht wirtschaftlich heraus oder schlicht als Bullshit. Während viele Startup-Buden den Bust nicht überlebt haben, waren große Konzerne erleichtert, wieder etwas weniger Innovationsdruck im IT-Bereich zu haben. Es musste weniger in Entwicklung und Forschung ausgegeben werden und weniger in Zukäufe wertloser, aber gut vermarkteter, Startups. Viele Bedrohungen sind in sich zusammengefallen und stellten kein Risiko mehr dar,
Alle waren froh, wieder einen Gang zurückschalten zu können, getreu dem Motto „Nichts wird so heiß gegessen, wie es gekocht wird.“
Im Zuge des Booms und des wirtschaftlichen Aufstiegs vieler Staaten in Osteuropa und Asiens (Indien), entspannte sich die Personalsituation international durch eine neue, große und günstige Zahl an Entwicklern.
Viele Unternehmen aus Deutschland verlagerten daraufhin einen Großteil oder gar die gesamte Software-Entwicklung ins Ausland: Entweder nach Osteuropa oder nach Asien. In Deutschland blieb nur eine Projektkoordinationstätigkeit übrig. Forschungsabteilungen gab es nur selten, Konzerne wie SAP verlegten diese ins Silicon Valley.
Man ging davon aus, dass die Technologie und Innovationsgeschwindigkeit sich auf absehbare Zeit nicht mehr substanziell verändern würde und die bestehenden Investments diese Anforderungen gerecht werden könnten. Software-Entwicklung wurde zu einer Commodity, die man nahezu standardisiert beziehen konnte.
Wäre es dabei geblieben, wäre dies alles eine betriebswirtschaftlich nachvollziehbare und sogar erstrebenswerte Entwicklung gewesen. Leider handelt es sich jedoch um einen Denkfehler:
Software-Entwicklungs-Technologie-Innovationen haben sehr volatile Zyklen. Es gibt Phasen von geringer Innovation, die dann von Hyper-Innovativen-Phasen abgelöst werden. Technologien und Trends sind, wenn überhaupt, nur für einen kurzen Zeitpunkt eine begreifbare, vorhersagbare Commodity und im nächsten Augenblick bereits hoffnungslos veraltet und tlw sogar eine Belastung für das Unternehmen.
Doch die Folgen waren noch viel weitreichender: Informatiker in Deutschland wurden nicht mehr selbst an der Entwicklung beteiligt, sondern übernahmen höchstens noch Architekturvorgaben, haben fleissig UML-Diagramme gemalt, PowerPoint-Präsentationen gebastelt und den Offshore-Entwicklern „Druck gemacht“. Sie haben verlernt, selbständig zu entwickeln, Probleme zu erkennen, Lösungen zu planen und umzusetzen. Stattdessen hat man sich auf eine Programmiersprache (Java) konzentriert und auf fertig zugekaufte oder Open Source Enterprise-Frameworks.
Das ist zwar in vielen Fällen besser, als das Rad selbst zu entwickeln, aber man sollte sich immer bewusst sein, was man sich hier ans Bein bindet. „Not invented here“ und „Invented here“-Antipatterns müssen immer berücksichtigt werden, eine Entscheidung diesbezüglich hängt von den Erfordernissen und des Projekt-Horizontes ab, ist meiner Meinung nach eine reine Einzelfallentscheidung die man technologieoffen treffen sollte.
Schlimmer noch als die Distanz zur eigentliche Entwicklung empfinde ich aber auch die Distanz zur Qualitätssicherung. Auch diese wurde outgesourced, denn Tester sind teuer, gerade in Deutschland. Auf die Idee TDD einzusetzen oder zumindest eine sehr starke, automatisierte Test-Infrastruktur aufzubauen kam man eher selten. Trotz des ganzen agile/SCRUM-Hypes, habe ich bisher kein Unternehmen erlebt, dass bswp SCRUM nach Lehrbuch lebte. Der In-House-Kunde, also der Business bzw Product Owner, war hier nie so gut wie nie beteiligt.
Der Lohnunterschied Offshore vs. Deutschland war lange der Vorteil dieser Lösung: Es war schlicht billiger als in Deuschland so viele „Experten“ anzuheuern.
Doch einerseits gab es seit 2005 wieder eine dramatische Beschleunigung in der IT, dutzende neuer Sprachen, Frameworks, Datenbanken, Verarbeitungskonzepte (vieles davon ist substanzhaltiger als beim Dotcom Boom) — andererseits wurde der Zeitfaktor (Time to market) immer kritischer. Ich kann die Entwicklungsgeschwindigkeit nicht mit mehr Personal erhöhen, auch die Qualität nicht. Und schon gar nicht durch eine „Lange Leitung“ zu Offshore-Entwicklern, inklusive Sprach und Kulturbarrieren. Hier müssen andere Projektmanagement-Methoden her, andere QA-Konzepte, andere Tools und eine andere Vorstellung von Software-Entwicklung!
Bis heute haben das die meisten Unternehmen nicht verstanden und glauben sich noch immer durch eine günstige Offshore-Entwicklung im Vorteil, währenddessen arbeiten aber schon Startups aus den USA mit lokalem Person an ihrer Ablösung. Viel günstiger, agile, flexibler, innovativer und mittlerweile auch globaler als die alten deutschen Tanker und auch als so manches hoch gelobte deutsche Start-Up.
Eigentlich müssten jetzt Unternehmen wie United Internet, die Telekom, große Handels- und Industriekonzerne signifikante Summen in die Hand nehmen um wieder lokale R&D-Kompetenzen aufzubauen.
Dazu fehlen die Leute mit Erfahrung und die Hochschulen die Leute ausbilden (die bis vor kurzem am besten gut 0815-JEE-Java können sollten). Das passiert nur sehr zögerlich oder überhaupt nicht. Konzerne wie SAP sind flexible genug und planen eine Zukunft lieber ohne Technologie aus Deutschland, haben dafür aber auch noch andere Probleme interne zu lösen. Das ist keine Erfolgsgarantie, aber eine Chance. Andere große Konzerne wie auch Startups in Deutschland sind technologisch nur noch passiv tätig, sind auf fertige, zugekaufte Lösungen angewiesen und konsumieren Open Source Software ohne diese selbst zu verstehen oder gar an der Weiterentwicklung zu helfen.
Java war eine Falle, eine Utopie.
Eine vermeintliche einheitliche, standardisierte Lösung für ein extrem volatiles teilweise damals noch nicht bekanntes Problem. Statt mit wechselnden Anforderungen und unsteten Technologien umgehen zu lernen, wurde fast schon religiös auf diese eine Karte gesetzt. Diese Karte verliert jedoch seit Jahren in vielen Bereichen an Boden. Noch immer haben viele Unternehmen dies nicht erkannt und zahlen gerade einen sehr hohen Preis dafür oder gehen schlicht unter.
Ich befürchte letzteres.