Bertal Dresen (BD): Ich möchte zu Beginn an ein Interview anknüpfen, das ich im Jahre 1987 als Hauptherausgeber der damals gerade neugegründeten Zeitschrift ‚Informatik – Forschung und Entwicklung‘ mit Ihnen führte [1]. Wir hatten uns über das Projekt START unterhalten, das damals nur wenige Jahre hinter Ihnen lag. Ich hielt nicht nur Art und Umfang des Projekts für sehr beachtenswert, sondern auch die von Ihnen benutzten Konzepte und Methoden. Welche Bedeutung hatte dieses Projekt für Sie, im Rückblick gesehen? Was waren die bleibenden Erfahrungen?
Ernst Denert (ED): Das START-Projekt hat mein berufliches Leben als Software-Ingenieur entscheidend geprägt. Es war – zumindest für die damalige Zeit, die zweite Hälfte der 70er Jahre − ein großes und innovatives Projekt, das mir die Gelegenheit bot, Ideen auszuprobieren, die ich von der Uni, der TU Berlin, mitgebracht hatte: hauptsächlich die Datenabstraktion als Prinzip der Modularisierung von Software. Ich hatte darüber bei David Parnas gelesen (z.B. seinen berühmten Artikel „On the criteria to be used in decomposing systems into modules“), erste Erfahrungen mit objektorientierter Programmierung in Simula gemacht und die algebraische Spezifikation abstrakter Datentypen von John Guttag studiert. Glücklicherweise konnte ich meine Kollegen bei Softlab dafür gewinnen, die Architektur der START-Anwendungssoftware mit Datenabstraktions-Moduln zu gestalten. So nannten wir unseren Vorläufer des OO-Designs. Ich glaube, wir waren weltweit die Ersten, die ein Softwaresystem in der Praxis derart konstruierten. (Es kann sein, dass Ivar Jacobsen zur selben Zeit Ähnliches gemacht hat.)
BD: Sie hatten 1982 zusammen mit Ulf Maiborn die Firma sd&m gegründet und waren recht erfolgreich. Welche allgemeinen Ratschläge würden Sie aufgrund Ihrer Erfahrung einem Informatiker mitgeben, der sich heute selbständig machen will? Wie kann er seine persönlichen Risiken klein halten und sich dennoch gut im Markt positionieren? Warum ist es sinnvoll, feste Preise für Projekte zu vereinbaren, statt nach Zeit und Kosten abzurechnen? Wie betreibt man am erfolgreichsten die Akquisition von Projekten?
ED: Mein wichtigster Rat: Nach der Hochschule erst einmal Erfahrungen in der Wirtschaft sammeln. Es reicht nicht, nur eine gute (Produkt-) Idee zu haben, man muss als Unternehmer den Markt und Kunden kennen, Geschäftsbeziehungen anbahnen und wirtschaften können, Mitarbeiter rekrutieren und führen lernen, kurz: Berufslebenserfahrung haben.
Ich stehe mit dieser Auffassung etwas im Gegensatz zu den Bestrebungen der Unis und Gründerzentren, die aus einem Doktoranden und seiner Dissertation umgehend einen Unternehmer mit seinem Produkt machen wollen. Ich halte es für wichtig, dass Jungunternehmer lernen, vom Geld ihrer Kunden zu leben und nicht von Investoren. Deren Kapital ist zwar notwendig, wenn man mit einem Produkt in den Markt will, aber verführerisch, weil man – zunächst – die Kunden nicht braucht und darüber vernachlässigt.
Ich stehe mit dieser Auffassung etwas im Gegensatz zu den Bestrebungen der Unis und Gründerzentren, die aus einem Doktoranden und seiner Dissertation umgehend einen Unternehmer mit seinem Produkt machen wollen. Ich halte es für wichtig, dass Jungunternehmer lernen, vom Geld ihrer Kunden zu leben und nicht von Investoren. Deren Kapital ist zwar notwendig, wenn man mit einem Produkt in den Markt will, aber verführerisch, weil man – zunächst – die Kunden nicht braucht und darüber vernachlässigt.
Es ist ganz gut, mit Aufwandsverrechnung zu beginnen, für Festpreisprojekte braucht man eine ordentliche Portion Erfahrung und ein finanzielles Polster. Unser erstes großes Festpreisprojekt haben wir bei sd&m auch erst nach drei Jahren gemacht. Ein Kollege bei sd&m sagte: „Jeder bekommt das Projekt, das ihm der Kunde zutraut.“ Bei der Akquisition kommt es eben auf die persönliche Ausstrahlung an, auf Kompetenz, Glaubwürdigkeit, Überzeugungskraft.
BD: Neben dem Projektgeschäft ist das Produktgeschäft für viele Software-Unternehmer eine zweite Säule. Wo sehen Sie die wesentlichen Unterschiede? Ist es primär die höhere Kapitalisierung, die erforderlich ist? Es gibt Kollegen, die meinen, dass beide Geschäfte sich sehr gut ergänzen. Wie sehen Sie das? Gibt es wesentliche Unterschiede in Bezug auf Entwicklungsmethoden und Projekt-Management?
ED: Bei sd&m haben wir ausschließlich Projektgeschäft betrieben, bei der IVU fast nur Produkte vermarktet, hauptsächlich Software, teilweise auch in Verbindung mit spezieller Hardware. Es ist ein großer Unterschied. Nicht so sehr in der Kapitalisierung, vielmehr in der Organisation und Arbeitsweise. Im Projektgeschäft sind die Mitarbeiter stark kundenorientiert, oft arbeiten sie beim Kunden, in der Produktentwicklung sind sie dagegen eher kundenfern und stehen mit den kundennahen Vertriebsleuten häufig im Konflikt. Außerdem ist die wirtschaftliche Lage weniger transparent als bei den Projektleuten mit ihren „billable hours“. In puncto Entwicklungsmethoden und Projekt-Management sehe ich dagegen weniger Unterschiede zwischen Projekt- und Produktgeschäft.
BD: Wie Sie 1993 in einem Gespräch mit dem Historiker Bill Asprey erwähnten, haben sich viele Leute bei sd&m beworben, weil sie so arbeiten wollten, wie Sie es in Ihren bekannten Buch [2] beschrieben haben. Sie vertreten darin eine sehr pragmatische Auffassung des Software Engineering. Nur vor CASE-Tools warnen Sie. Wo sehen Sie heute die Hauptprobleme der Software-Entwicklung? Gibt es neuere methodische Ansätze, die wesentlich über den Stand von 1991 hinausgehen? Hat die Tätigkeit für die IVU möglicherweise Ihre Sicht verändert? Wie beurteilen Sie die Hochschulausbildung im Fach Software-Engineering?
ED: Die CASE-Tools fand ich aus zwei Gründen ungeeignet, ja geradezu gefährlich: Erstens basierten sie auf Structured Analysis (SA), einer grafischen Methode, die dem objektorientierten Paradigma diametral entgegengesetzt ist. Und zweitens halte ich das Generieren lauffähiger Softwaresysteme aus einer irgendwie gearteten Spezifikation, gar einer SA-Grafik, für einen ewigen Informatikertraum.
In meiner aktiven Zeit als Software-Ingenieur hatten wir relativ einfache Entwicklungsumgebungen: einen Editor, ein Dateisystem, eine Programmiersprache mit ihrem Compiler, oft aus einer Hand, von einem Hersteller wie etwa IBM. Damit haben wir Anwendungen programmiert, die auf einem Betriebssystem, eventuell mit Transaktionsmonitor, und einem Datenbanksystem laufen mussten. Heute sind die Werkzeuge viel mächtiger, aber auch komplexer und schwerer zu beherrschen. Bis ein Framework von einem Team wirklich beherrscht, effizient und einheitlich genutzt wird, gibt es eine Menge Fehler.
In den Grundsätzen des Software-Engineerings hat sich seit 1991 nicht so viel geändert – sofern man nicht der agilen Glaubensgemeinschaft beigetreten ist –, in der Technik jedoch sehr wohl: die Plattformen, für die wir heute entwickeln, und die Mittel dafür (Programmiersprachen und -umgebungen) sind anders, erheblich leistungsfähiger und damit komplexer. Das habe ich zuletzt bei der IVU erlebt und erlitten.
Die Informatikausbildung an den deutschen Hochschulen und Universitäten halte ich für gut. Einen Gutteil meines beruflichen Erfolgs verdanke ich ihren Absolventen.
BD: Sie haben sich öfters dazu geäußert, welche Personalpolitik ein Unternehmer in der Software-Branche betreiben soll, um Erfolg zu haben. Es beginnt mit der Auswahl geeigneter Mitarbeiter, über ihre Weiterbildung bis hin zu Laufbahnfragen, Mitbeteiligung und Vergütung. Was halten Sie heute für die wichtigsten Prinzipien einer guten Personalpolitik? Welche Unterschiede gilt es zu beachten zwischen Firmen, die Projekte für andere Unternehmen machen (wie sd&m), und solchen, die primär eigene Anwendungen entwickeln (wie IVU)? Wie sehen Sie das Verhältnis zwischen Informatik und Fachabteilungen?
ED: Eine gute Personalpolitik fängt mit der Auswahl der richtigen Mitarbeiter an. In einem Vortrag auf der SEUH-Tagung in Stuttgart im Jahre 2007 [3] habe ich die Anforderungen beschrieben, zusammengefasst: eine sehr gute informatische Ausbildung und eine starke Persönlichkeit. Unter einer guten Führung ist dann eine hohe Leistung der Einzelnen und des Teams selbstverständlich, ein paar Merkmale in der Unternehmenskultur vorausgesetzt: offene Kommunikation über (fast) alle Unternehmensbelange − gute und schlechte Nachrichten gleichermaßen −, Verständnis für die Mitarbeiter, Fairness und Gerechtigkeit, interessante Aufgaben, Freiraum und Verantwortung.
Einen großen Unterschied in der Personalpolitik zwischen Projekt- und Produktunternehmen sehe ich nicht, allenfalls müssen Produktentwickler mehr angehalten werden, ihre Anwender besser zu verstehen, als die Projektleute, die in den Fachabteilungen ihren eigentlichen Auftraggeber sehen.
BD: Sie haben 1989 die Ernst Denert-Stiftung gegründet, um – wie Sie sagen – der Gesellschaft und der Informatik im Besondern etwas zurückzugeben. Haben sich hier Ihre Erwartungen erfüllt? Was könnte evtl. besser laufen?
ED: Ja, die Stiftung macht mir Freude und auch ein wenig Arbeit, beispielsweise die Vergabe des Software-Engineering-Preises, der seit fast 20 Jahren vergeben wird und sich eines beträchtlichen Renommees erfreut. Die Initiative „Informatik studieren!“ lässt sich gut an, sie verfolgt ein wichtiges Ziel: mehr junge Leute für das Informatikstudium gewinnen. Die Stiftung wird vom Stifterverband für die Deutsche Wissenschaft verwaltet. Damit bin ich sehr zufrieden.
Ich fange an, darüber nachzudenken, wie es langfristig weitergehen soll. Eine Stiftung ist ja erst einmal für die Ewigkeit angelegt, aber ich kann mir nicht vorstellen, dass sich 20 Jahre nach meinem Tod noch jemand für die Ernst Denert-Stiftung interessiert oder sie gar inhaltlich weiterführt. Was also tun: Auslaufen lassen, d.h. das Vermögen verbrauchen, oder es in eine andere Stiftung übertragen?
BD: Sie haben sehr viel Zeit und Energie für die Gesellschaft für Informatik (GI) aufgebracht. Warum taten Sie dies, obwohl der Hauptberuf Sie sicherlich sehr forderte? Was raten Sie Kollegen aus der Industrie in dieser Hinsicht?
ED: Auf diese Frage möchte ich nicht eingehen, nachdem ich im März als GI-Vizepräsident zurückgetreten bin.
BD: Herr Denert, vielen Dank für das Interview. Ich bin überzeugt, dass auch dieser Gedankenaustausch zweier älterer Herren auf Interesse bei meinen Lesern stößt. Dass Ihr Engagement für die GI diese Wende nahm, war mir neu. Es tut mir leid, dies zu hören.
Zusätzliche Referenzen:
1. Das START-Projekt. Interview mit Dr. Ernst Denert. Inf. Forsch. & Entw. 2,1; 49-52
2. Denert, E.: Software Engineering. Heidelberg 1991
3. Denert, E.: Was wir vom Software-Ingenieur erwarten: Gleichgewicht von Fachwissen und Persönlichkeit. In: Zeller, A., Deininger, M.: (Eds.): Software Engineering im Unterricht der Hochschulen, SEUH 10. Heidelberg 2007, 1-5
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.