>
<
© 2003 Florian Greese

Was machen eigentlich Softwareentwickler?

Gedanken zu meinem Dasein als Softwareentwickler.

Kurze Antwort: Softwareentwickler übersetzen Anforderungen von Menschen in Anweisungen für Computer (z.B. von Deutsch nach Java, einer "modernen" Programmiersprache ).

Daraus ergeben sich grundlegende Fähigkeiten (neudeutsch Skills), die ein Programmierer haben sollte:

Gerade der letze Punkt ist die Ursache der meisten (und gravierenden) Softwarefehler.

Werkzeuge

Schon die Worte "Computer" und "Programmieren" rufen bei den meisten Menschen diesen "Das ist mir zu kompliziert" Gesichtsausdruck hervor. Doch keine Bange, hier geht es nicht um das Programmieren-lernen, sondern um einen Eindruck über die Arbeit eines Softwareentwicklers.

Fangen wir doch mit einer Analogie an:
Ein Autor kennt sich mit seinen Werkzeugen (Textverarbeitungsprogramm oder Schreibmaschine) sehr gut aus, beherrscht die Rechtschreibung, Grammatik und Erzählstile.
Einem solchen Autor wird es nicht schwerfallen, einen Zeitungsartikel oder ein Buch zu schreiben.

Ein Programmierer kennt sich mit seinen Werkzeugen (Programmiersprachen, Editoren usw.) aus, beherrscht das Computer-Know-How und die Programmiertechniken.
Einem solchen Programmierer wird es ebenfalls nicht schwerfallen, ein Programm für eine bestimmte Aufgabe zu schreiben.

Aufgaben

Die wirklichen Probleme liegen im Verstehen der Anforderungen und deren Umsetzung.
Lautet z.B. die Anforderung an den Autor:
"Schreiben Sie bitte einen 500 Seitigen Liebesroman mit 4 Todesfällen und 2 Hochzeiten"
oder an den Programmierer:
"Schreiben Sie bitte ein tolles Textverarbeitungsprogramm, das alles kann, was die Konkurenz auch bietet und zusätzlich noch einige neue Features hat, welches der Anwender unverzichtbar finden wird",
dann werden sich diese beiden Menschen hinsetzen und nach bestem Wissen und Gewissen das tun, was sie unter diesen (zugegeben arg schammig konstruierten) Anforderungen verstanden haben.
Das Ergebnis wird den Auftraggeber nicht zufriedenstellen. Vielleicht hätte es doch kein Liebesroman, sondern ein Krimi mit Romanze werden sollen? Textverarbeitung war vielleicht zu eng gefasst, wo ist die Tabellenkalkulation, das Präsentationsprogramm?

In der Realität werden solche Anforderungen im Gespräch mit dem Auftragsgeber erstmal konkretisiert und anhand von Grobskizzen und Demonstrationen verfeinert.
Bis nun die konkreten Anforderungen feststehen vergeht erstmal eine Menge Zeit. Bis zur Umsetzung in ein reales Produkt (inkl. Qualitätssicherung) dauert es nochmals sehr lange.
Soll das Produkt auch noch verkauft werden, muss auch die Markteinführung geplant werde. Werbung usw. ist notwendig, damit sich auch Käufer finden.
So etwas funktioniert besser, wenn es für die Produktentwicklung einen Plan gibt.

In der Softwarebranche gab es vor der sogenannten DotCom Krise sehr lange Produktzyklen (d.h. vom Auftrag bis zum verkaufsfertigen Programm dauerte es oft mehrere Jahre).
Heute ist es erwünscht, wenn diese Zyklen sich im Halb- oder Ganzjahresrahmen bewegen, also deutlich kürzer sind. Dabei bleiben die Anforderungen in etwa gleich. D.h. man will die selbe Produktart in der gleichen oder besseren Qualität in der Hälfte (oder weniger) Zeit herstellen.

Dies ist mit den bisherigen Prozessplänen sicher nicht ohne Abstriche machbar. Sie kennen dies auch: Wenn Sie ein neues Programm in der Version 1.5 erwerben, dann hat es noch sehr viele Fehler, die Sie dem Hersteller melden dürfen. Dieser bringt dann einige Zeit später die Version 2.1 heraus, in der die bekannten Fehler behoben und neue Features mit neuen Fehlern hinzugekommen sind. Ach ja und zahlen dürfen Sie für eine solche Korrektur auch noch, da Sie ja neue Features bekommen.

Wir Entwickler müssen also unsere alten Produkte pflegen, d.h. Fehler korrigieren und am Leben erhalten, d.h. neue Features einbauen.
Die Korrektur von Fehlern ist eine ungeliebte Sache, denn der Aufwand ist sehr hoch, der Gewinn eher gering. Dennoch gilt: Fehlerhafte Produkte schaden dem Ansehen/Ruf einer Firma.
Es gibt eine ganze Menge Literatur zu diesem Thema, deswegen gehe ich auch nicht weiter auf diese "dunkle Seite" des Entwicklerdaseins ein.

Was bleibt, ist eine Lücke zwischen der (konkreten) Anforderung und der Realisierung des Produktes, also zwischen dem was gefordert und gewollt wurde. Diese Lücke beinhaltet auch einen zeitlichen Abstand zwischen Anforderung und fertigem Produkt.
Wenn es zu lange dauert, bis ein Produkt fertig ist, kann es evtl. nicht mehr auf den Markt gebracht werden. Je kürzer also der zeitliche Abstand zwischen Anforderung und Produktrealisierung ist, desto besser. Die Softwareentwicklung macht hierbei einen grossen Teil aus.

Der Weg ist das Ziel

Als Programmierer ist es meine Aufgabe, nicht nur die Anforderungen zu erfüllen und das "richtige" Programm zu schreiben, sondern auch einen Weg zu finden, die o.g. Lücke zu verkleinern.
In kleinen, aber stetigen Schritten entwicklen sich die Werkzeuge weiter. Es entstehen neue, abstraktere Sprachen. Die Lücke wird kleiner, aber nur sehr langsam.
Es ist auch aufwändig, einigermaßen auf dem laufenden zu bleiben. Ich selbst wende ca. 10% meiner (Arbeits)Zeit für das Lernen von neuen Dingen auf. Der Aufwand macht sich bezahlt. Mit jeder neuen Aufgabe überprüfe ich, welche Werkzeuge für diese am besten geeignet sind, d.h. mit welchen Mitteln habe ich eine möglichst kleine Lücke zwischen Anforderung und Realisierung.

Manchmal gibt es auch Entwicklungen, welche die aufgestauten Wissensfragmente plötzlich zusammenfügen. So geschehen mit XML und XSLT.
Ein Programmierer löst also nicht nur Kundenprobleme sondern verbessert nebenbei auch die Produktivität, in dem er sich Arbeitserleichterung durch neue Programmiersprachen oder sonstige Werkzeuge verschafft.

Was der Kunde will

Soweit aus der Programmierersicht. Der Kunde hat meist sein eigenes Vokabular. Ein Kriminologe, ein Anlageberater, ein Bauingenieur oder ein Großbäcker sprechen völlig unterschiedliche Fachsprachen. Der Auftragnehmer muss sich für jeden Kunden in seine Fachsprache reinhören/denken und schmecken und diese dann in ein Programm gießen (lassen).
Vielleicht werden alle Programme der unterschiedlichsten Kunden mit der selben Programmiersprache (Java??) erstellt. Sie können sich sicherlich vorstellen, welche gedanklichen Hirnverwindungen es den Programmierer kostet kundenspezifische Programme, termin- und qualitätsgerecht fertigzustellen.

Genau dieses "sich hereindenken" in die Kundenspezifischen Probleme macht für mich den Reiz des Programmiererdaseins aus. Es gibt jedesmal etwas zu lernen. z.B. über die Bestückung von Hochöfen bei Stahlwerken, über die Fehlermeldungstechnik der Bandstrassen bei einem Autohersteller, die Logistik von Just-In-Time Zulieferungen oder die genaue Funktionsweise der Datenübertragungstechniken.
Manchmal ist so etwas unbequem und schwierig, doch überwiegt der motiviernde Spaß, insbesondere wenn ich eine (neue) Möglichkeit erkenne das Problem elegant und effizient zu lösen.

Es wäre müßig, für jeden Kundentyp eine eigene Programmiersprache zu erfinden. Auf der anderen Seite ist eine gewisse Formalisierung der Auftragsbeschreibung nicht schlecht. Es gibt zwar sogenannte Pflichtenhefte, doch diese sind alles andere als eindeutig.
Wenn es gleingt, den Auftrag eines Kunden in einer kundenspezifischen Notation (ad hoc) formal zu beschreiben, dann könnte man doch daraus gleich das Programm erzeugen. (hehe kleiner Scherz!).

Aussicht

Wie schon erwähnt, hat XML hier neue Möglichkeiten geschaffen. Denn mittels XML ist eine computerlesbare ad-hoc Formalisierung von Aufträgen in greifbare Nähe gerückt. Stat nun ein Programm in Java zu schreiben, baut der findige Programmierer eine "Fabrik" (z.B. in XSLT) für diese kundenspezifische ad-hoc Sprache, welche dann das passende Programm baut. Nun sind Änderungswünsche des Kunden sehr viel leichter und schneller zu realisieren als bisher.
Das geht nicht meinen Sie? Ich sage, es geht! Diese Homepage wurde z.B. mit einer solchen Technik erzeugt.

Sie haben bis hier her gelesen? Prima dann wissen Sie nun in etwa, was ich, als Softwareentwickler, den Arbeitstag lang mache.

Vielen Dank für's Lesen, sagt Florian