Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.03.1990

Den idealen Software-Entwickler gibt es nicht

Frank D. Peschanel

Geschäftsführer der FFS für Unternehmensentwicklung in Unterwössen

Auch in der Software-Entwicklung geht der Taylorismus seinem Ende entgegen.

Als Software-Entwickler muß man durch und durch logisch und rational sein. Die kleinste Abweichung von der richtigen Logik, und schon kommt etwas ganz anderes heraus. Also: man finde die logischsten Köpfe und bekomme so die besten Programme. Dachte man Ende der sechziger Jahre. Und erfand bei IBM den PET, den Programmer Evaluation Test, den Eignungstest für Programmierer. Wollte man in den siebziger Jahren etwas werden, bei der IBM oder bei einem größeren IBM-Anwender (also bei 80 Prozent der damaligen Anwender), so mußte man im PET in der Kategorie A oder bestenfalls B herauskommen. Die IBM gab diesen Test, den Tausende und Tausende (zum Teil mehrfach) machten, unter der Hand an die IBM-Anwender. Die älteren Entwickler, oft damals so ausgewählt, inzwischen vorgerückt auf leitende Positionen, werden sich erinnern: Reihen und Folgen, eingekleidete Aufgaben, Figuren erkennen und zuordnen.

Gerhard T. Weinberg zitierte schon 1971 mehrere Veröffentlichungen, die bewiesen, daß dieser "Eignungstest" nie an seiner Wirkung in der Praxis validiert worden war. Vielmehr wurde dieser Test an Programmierstudenten entwickelt und so aufgebaut, daß er gutes Abschneiden in den Abschlußprüfungen vorhersagte. Mehrere Versuche, in der Praxis eine Verbindung zwischen guten PET-Testergebnissen und guter Leistung im Beruf nachzuweisen, schlugen fehl. Trotzdem wurde ein gutes Jahrzehnt lang mit diesem Test mit voller Kraft gearbeitet; die IBM hat erst Ende der achtziger Jahre diesen Test im eigenen Hause abgeschafft.

Was war so attraktiv am PET, daß man ihn eisern weiter nutzte, obwohl seine Wirksamkeit für die Vorhersage der Leistung am Arbeitsplatz nicht zu beweisen war? Wenn man den PET in seinem Aufbau betrachtet, so testet er zu etwa 80 Prozent tatsächlich logische, rechnerische, algorithmische Fähigkeiten und liegt damit nahe bei dem klassischen Intelligenztest IQ. Zurückblickend kann man feststellen, daß dieser PET-Test deswegen so beliebt war, weil alle glaubten, Programmieren sei eine absolut logische Angelegenheit - deswegen müßten Programmierer "auf eine bestimmte Weise logisch-rationale Denker sein". Alle fühlten mit Recht, daß der PET genau das testete, 15 Jahre lang wurde mindestens 70 Prozent aller Einstellungen mit diesem Test und diesem Glaubensbekenntnis des rationalen Programmierdenkens vorgenommen - mit dem Ergebnis, daß die Datenverarbeitung geradezu solche "logisch-rational-linear-Denker" anzog. Genauer: Diese Art von Denktypen wurde ganz gezielt herausgefiltert und eingestellt. Auf diese Weise reicherte sich der logisch-rationale Typ in der Datenverarbeitung immer mehr an, bis es geradezu selbstverständlich war, dazuzugehören.

Der schon zitierte Gerald T. Weinberg erkannte die Risiken dieses Vorgehens schon 1971.

Seine Experimente als Chef einer Software-Entwicklergruppe und als Computer-Science-Professor, zum Beispiel zur Produktivität von Entwicklern, brachten ihn zu einer ganz anderen Erkenntnis. Er schrieb:

"Computer Programming is a Human Activity", und er meinte damit: Programmieren verläuft im menschlichen Geist nicht so, als sei man selbst im Kopf ein Computer. Er wies in zahlreichen Beispielen auf ganz andere Aspekte des Denkens als Erfolgsfaktoren hin, als Logik und Rationalität. Zum Beispiel auf die experimentell verifizierte wirtschaftliche Bedeutung einer Kaffeemaschine als informelles Kommunikationszentrum.

Heute wissen wir, daß der von PET im wesentlichen getestete Denkstil nur einer von mehreren erfolgsrelevanten Denkstilen ist. Und daß durch die Filterwirkung des PET ganze Generationen von EDV-Novizen ganz einseitig zugunsten dieses einen Denkstils ausgewählt worden sind - und bis heute die Branche prägen.

Denkstile. Das ist ein neuer Begriff, der in den letzten Jahren immer wichtiger wurde. Denkstil: die Art, wie ein Individuum denkt. Denkstile kann man heute "messen". Ein wichtig werdendes Verfahren, das sozialwissenschaftlich validierte Hirndominanz-Instrument nach Ned Harrmann, baut den Denkstil eines Individuums aus vier Komponenten auf:

A: Logisch, analytisch, faktenbezogen, mathematisch, wortbezogen.

B: Sequentiell, konservativ, regelbezogen, detailorientiert, geplant und organisiert.

C: Zwischenmenschlich, gefühlsbezogen, musikalisch.

D: Konzepte bildend, ganzheitlich, erfinderisch, kreativ, visuell.

Im Muster dieser vier Denkstiltypen filterte der PET-Test als "idealen Datenverarbeiter" etwa mit 60 Prozent A, 30 Prozent B, 0 Prozent C, 10 Prozent D aus.

Das heißt zum Beispiel, daß bei dem Aufbau der EDV-Mannschaften "Kundenbezogenheit" (C) mit 0 Prozent keine Rolle gespielt hat und in dem formalen Eignungstest gar nicht enthalten war. Und daß individuelle Anwender-Interfaces wie beim Mac (D-Stil) von den ernsten Datenverarbeitern (A- und B-Stil) zunächst als "Kinderspielzeug" abgetan wurde. Es lebe die Command Language (gehört zum A-Stil)!

Am Beispiel des Mac-Interface im Vergleich mit dem MS-DOS-Interface kann man sehen, wie unterschiedliche EDV-Produkte A-Denken und D-Denken herausstellen. Und Sie können jetzt objektiv erkennen, welche Rolle ein Defizit von C-Denken spielt, wenn es um anwenderbezogene Entwicklungen geht. Vor einigen Wochen saß mir in einem Berliner Softwarehaus ein junger Entwickler gegenüber. Ich sagte ihm auf den Kopf zu, daß er menschlich gern und viel mit dem Kunden arbeitet, und daß er vermutlich keinerlei Probleme habe, zum Beispiel in der Analysearbeit mit dem Kunden lange Zeit damit zu verbringen, auch kleine Details sorgfältig zu klären. Er war sehr erstaunt und stimmte dieser Einschätzung völlig zu. Der ganze Trick: Ich kannte sein Denkstilprofil und wußte, daß er - sehr unüblich für einen Entwickler - die Denkstile B und C bevorzugte. Ich habe einige Zweifel, ob er den PET brauchbar bestanden hätte, sein Profil ist geradezu das Gegenteil des historisch typischen Entwicklers nach PET.

Was heute feststeht und meßbar ist: Ganz unterschiedliche Denkstil-Typen haben in der Software-Entwicklung Platz. So zu tun, als gäbe es den "idealen Entwickler", ist ein historischer und überholter Fehlschluß. Software-Entwicklung hat sehr viel mit Kreativität und Konzeptbildung (D) zu tun, wenn es um Design geht.

Expertentum, zum Beispiel in Datenbanken, und Informatiktheoretisches Wissen gehören zum A-Stil. Projektabwicklung, Kostenkontrolle, Qualitätskontrolle, Implementieren gehören stark zum B-Stil. Kundenbezug, gute Help-Funktionen, angenehme User-Interfaces gehören zum C-Stil.

Das Schöne daran: Es ist Platz für sehr unterschiedliche Entwicklertypen in der Softwareentwicklung. Danach zu streben, der ideale Entwickler zu sein, "die richtige Entwickler-Denke zu haben", ist Unsinn. Die Aufgabe heißt, sich selbst als Entwickler klar darüber zu werden, in welchem Aufgabenbereich die eigenen Stärken liegen - und diese Stärken dann weiter zu entwickeln und sich der eigenen Schwächen bewußt zu werden. Dies ist nichts als eine Grundregel guter Personalarbeit, Stärken und Schwächen der Leistung zu erkennen und damit gezielt zu arbeiten.

Das Problem dabei: die oben dargestellten Erkenntnisse sind im Software-Entwicklungs-Management noch weitgehend unbekannt - und viele Entwicklungs-Manager halten gern an der Fiktion des "richtigen Entwicklers" fest, denn dann braucht man nicht so komplizierte Dinge zu tun, wie die Individualität eines Mitarbeiters zu berücksichtigen.

Ich wurde einmal auf einer Informatik-Tagung nach einem Vortrag von einem Teilnehmer erbost gefragt: "Und soll ich nun Psychologie studieren?" Diese Einstellung hilft nicht weiter. Software-Entwicklung ist eine menschliche Tätigkeit. Es wird Zeit, daß wir die Individualität der Entwickler erkennen und beim Einsatz, zum Beispiel auch im Team-Management, berücksichtigen.

Es ist an der Zeit, den Taylorismus in der Software-Entwicklung zu überwinden. Menschenbezogenheit wird dabei unumgänglich sein, Psychologie werden Sie dabei nicht studieren müssen.