Jan Varwig

The Hard Part

Über die Mailingliste zur Vorlesung Rechnergestützter Entwurf von Mikroelektronik erreichte mich heute morgen ein Hinweis unseres Professors auf die Informatiktage in Bonn. Dabei handelt es sich um

[...] die Informatiktage, bei denen ausgewählte Studierende auf Unternehmensvertreter treffen. Die ca. 100 Teilnehmerinnen und Teilnehmer der Informatiktage müssen sich um die limitierten Plätze bewerben und werden durch unser Hochschulnetzwerk ausgewählt. Im persönlichen Gespräch, in Workshops oder Präsentationen lernen interessierte Unternehmen auf den Informatiktagen einen viel versprechenden Nachwuchs kennen.

Beim Klicken durch die Workshops stach mir folgender Text ins Auge

Vor dem Hintergrund der sich zunehmend verschärfenden Wettbewerbsbedingungen sehen sich viele Unternehmungen vor der Herausforderung, Kosteneinsparungspotentiale in sämtlichen Unternehmensbereichen zu identifizieren und zu evaluieren. Folglich haben sich auch die Anforderungen an die Informationstechnologie (IT) als Basis für die Unterstützung sämtlicher Geschäftsprozesse wesentlich erschwert. So muss die IT einerseits hoher Flexibilität genügen, um durch technologische Agilität die Wettbewerbsfähigkeit der Unternehmung in sich schneller verändernden Märkten zu gewährleisten.

Was für Ambitionen und Vorbilder man als junger Informatiker oder Programmierer auch haben mag, Formulierungen wie diese können in wenigen Sätzen Träume zerschmettern. Aus einem Interview mit Oliver Nazet, COO der Steria Mummert Consulting im “Karriereführer IT 2006″:

Welche Aufgaben nehmen sie als Chief Operation Officer des Unternehmens wahr?
Mein Aufgabe ist die Steuerung und kaufmännische Verantwortung des gesamten operativen Geschäfts. Dazu zählen auch die Bündelung unserer Kompetenzen und die Vernetzung unserer Technologieleistung mit unserem branchenspezifischen Portfolio. Denn nur duch dieses integrierte Arbeiten schaffen wir Mehrwert und befördern die Transformationsprozesse unserer Kunden.

Wut the fuk?
Wenn ich sowas lese zweifle ich daran, dass in deutschen Softwareunternehmen wirklich Sachkompetenz gefordert ist. Viel wichtiger scheint, in jedem Satz möglichst viele Buzzwords unterzubringen. Im Ernst: die Stellenbeschreibung des COO aus dem Zitat enthält null Informationen. Was man mit Sicherheit sagen kann, ist, dass die Firma Kunden hat, der Rest ist heisse Luft.

Zu schaffen macht mir, dass in Deutschland die Aufgabe der Softwareentwicklung scheinbar einzig und allein darin gesehen wird, “bestehende Geschäftsprozesse zu optimieren”. Software die dazu dient, die Aufgaben von Buchhaltern mit Rechnern erledigen zu lassen. Daher wundert es auch nicht, dass die Integranova GmbH mit einem automatischen Programmiersystem den eigentlichen Programmiervorgang vollständig abschaffen will:

Die manuelle Erstellung von Programmen ist nur eine Zwischenstufe auf dem Weg zur Industrialisierung der Softwareproduktion. Die Zukunft liegt in der weitgehend automatischen Abwicklung des Softwareentwicklungsprozesses, bei der der Softwareingenieur ausgehend von den Anwenderanforderungen die Produktion kreativ plant, gestaltet und steuert, aber kaum noch eigenhändige Programmierarbeit leistet. Umfassendes Qualitätsmanagement, Robustheit, Sicherheit und Benutzerzentrierung stehen dann im Vordergrund und nicht mehr die Erstellung immer wieder ähnlicher Programme. Ich bin beeindruckt von dem Pioniergeist und dem Elan, mit dem sich CARE-T dieser Herausforderung stellt, und welche Leistungsfähigkeit das von ihr entwickelte Werkzeug bereits erreicht hat.

Nach den Informationen auf der Webseite des Unternehmens handelt es sich bei der OLIVANOVA Programmiermaschine um ein UML-Modellierwerkzeug, dass aus den zusammengeklickten Modellen automatisch Client/Server-Programme in VB, C# oder Java erstellt. Diese Vison, Softwareerstellung klassischem Engineereing anzugleichen habe ich mir auch während des Studiums oft anhören müssen. Doch dabei wird immer wieder eine wichtige Tatsache unerwähnt gelassen: Bei der Softwareentwicklung liegt, anders als im Maschinenbau, die Schwierigkeit und der Großteil der Kosten nicht in der Herstellung, sondern im Design. Es ist verdammt hart, ein korrektes und konsistentes Modell zu entwerfen.
Dieses Problem ist es doch, was der agilen Entwicklung zugrunde liegt, die sich nicht umsonst zunehmender Beliebtheit erfreut. Software wird als Entwurf und nicht als Fertigung betrachtet und dementsprechend der Entwicklungszyklus darauf ausgerichtet, dass sich das Modell ändern kann sobald neue Erkenntnisse über das zu lösende Problem gewonnen werden.

Das “automatische Generieren” von Programmen ist daher keineswegs die Zukunft sondern der Versuch, ein überholtes Modell der Entwicklung zu bewahren: das BDUF, Big Design Up Front oder “Wasserfallmodell”, bei dem Software nicht iterativ, sondern seriell entwickelt wird, das Entwickler folglich zwingt zu Beginn ein fehlerfreies Modell zu erstellen und dieses dann umzusetzen. Zeigen sich Lücken im Design, heisst es “zurück auf Los” weil in einem starren Schema kein Platz für nachträgliche Änderungen ist. Einzige Chance auf ein bißchen Flexibilität ist es, den kompletten Zyklus zu beschleunigen und das wird hier versucht. Indem alle dem Design nachgeordneten Schritte entfallen oder automatisiert werden ist es möglich, auf sich ändernde Designs schnell zu reagieren.
Dabei müssen nichttriviale Zusammenhänge im Modell aufgrund der graphischen Prgorammierung in UML allerdings zwangsläufig auf der Strecke bleiben. Entweder werden komplexe Beziehungen nach wie vor von Hand in das generierte Programm eingefügt, wobei die Konsistenz mit dem Modell dabei wieder in der Hand des Programmierers liegt oder aber sie lassen sich bereits im Modelliersystem beschreiben. Ein solcher Sachverhalt führt dann bloß zwangsläufig zu der Frage, welchen Sinn das Modelliersystem überhaupt erfüllt. Komplexe Abläufe mit einem graphischen Editor zu erstellen ist einer textuellen Eingabe immer unterlegen. Graphische Darstellungen sind einfach nicht abstrakt genug um klar und präzise Beziehungen auszudrücken, darüberhinaus ist die Navigation per Maus, Menüs und Formularen wesentlich aufwendiger als das Tippen von Code.

Als Anwendungsfeld für die automatische Programmgenerierung kommen daher nur einfache CRUD-Datenbankfrontends in Frage und was für ein Leben ist das denn, Tag ein, Tag aus CRUD-Shovelware von der Stange zu produzieren?

Einer der letzten Blog-Einträge von Steve Yegge und die großartige OOPSLA ‘97 Keynote von Alan Kay die ich die Tage zum ersten Mal gesehen habe, schlagen in eine ganz andere Kerbe, zeigen Perspektiven die neugierig und unternehmungslustig machen.

Der erste Schritt ist, sich bewusst zu werden, wie beschränkt Computer eigentlich sind und zu erkennen, wie sehr die Informatik eigentlich in festgefahrenen Paradigmen festhängt. Das schlimme ist, wenn man sich einmal umgedreht und erkannt hat, dass man sich jahrelang kaum von der Stelle bewegt, ist es unmöglich dem alten Pfad weiter zu folgen. Das merke ich gerade ganz konkret an meiner Arbeit mit PHP und .NET. Nachdem ich die Mächtigkeit dynamischer Sprachen wie Ruby und Lisp zu schätzen gelernt habe, tut es fast weh mit Krücken wie C# oder — noch schlimmer — PHP umgehen zu müssen. Was sich vorher mit wenigen Zeilen zu einer eleganten Lösung formen ließ, erfordert auf einmal wieder das Basteln wackeliger Hilfskonstrukte und Umgehen von Unzulänglichkeiten mit einem Ergebnis das alles andere als zufriedenstellend ist.

Meine Sorge ist, dass es in Deutschland kaum Jobs gibt die einem solchen Verständnis von Software Rechnung tragen. Aber dann bleibt immernoch die Selbstständigkeit :)