Suche

Entwickler in den Fängen des Marketings

Der Softwareentwickler in der Praxis

Der Softwareentwickler erhält eine Aufgabe, die er lösen muss. Wie er sie löst, bleibt ihm überlassen. Die Kreativität und das Know-how des Entwicklers verleiten ihn oftmals dazu, neue und unspezifizierte Features hinzuzufügen [3]. Dem Entwickler mögen die zusätzlichen Funktionen sinnvoll und wichtig erscheinen. Sind sie es aber auch für den Kunden? Ist der entstehende Mehraufwand gerechtfertigt? Wie sieht es mit der Stabilität des Systems aus, da unspezifizierte Funktionalitäten nicht getestet werden? Allzu oft sind die Anforderungen (Pflichtenheft etc.) nicht eindeutig formuliert und der Entwickler trifft bei der Implementierung eigene Entscheidungen, was dazu führt, dass der Kunde etwas erhält, was nicht dem entspricht, was er eigentlich haben wollte.

Hinzu kommt, dass man immer mit den neuesten Technologien arbeiten will. Nicht nur wegen dem Produkt, sondern auch, um sich persönlich weiterzuentwickeln und um das Problem möglichst „State-of-the-Art“ zu lösen.

Je mehr Funktionalität, Technologien etc. in einem System vorhanden sind, umso so höher ist auch dessen Komplexität. Dementsprechend steigen die Aufwände für Wartung und Erweiterungen, aber auch die Lieferzeiten neuer Releases. Es wird zudem immer schwieriger, nicht den Überblick zu verlieren. Aus diesen Gründen ist es wichtig, dass man sich auf das Wesentliche konzentriert: „Was wird eigentlich gefordert?“ (Kasten: „Pareto-Prinzip“)

Das Pareto-Prinzip (80:20-Regel)

Das Pareto-Prinzip, benannt nach dem italienischen Ökonom Vilfredo Federico Damaso Pareto, besagt nichts weiter, als dass mit 20 % der Ursachen 80 % der Wirkung erzeugt wird. Anders formuliert, 20 % des Aufwands erzeugen 80 % des Nutzens. Stellen wir uns beispielhaft eine Datenbankanbindung vor. Diese ist innerhalb kürzester Zeit programmiert. Sollten die Datenbankparameter konfigurierbar sein? Ok, das Einlesen einer XML-Datei wird programmiert. Naja, andere Formate wären auch denkbar. Programmiert! Und die Performance – dürfte es StoredProcedures sein? Sicher doch! Und wie wäre es mit einem DBConnectionPool? Na klar, den brauchen wird auch! Sollte die Konfiguration nicht über ein separates GUI möglich sein? Mit Benutzerverwaltung?

Dieses kurze Beispiel zeigt deutlich das Pareto-Prinzip. Die Datenbankanbindung ist schnell realisiert und damit sind auch 80 % des Nutzens hergestellt. Aber dieser Leistungskern (Kernnutzen bzw. Kernfunktionalität) wird dann mit vielen weiteren Funktionalitäten umstrickt, die zwar den Nutzen steigern, jedoch auch den größten Teil des Aufwands (Kosten) darstellen. Die Kosten zur Realisierung des Leistungskerns, das, was der Kunde eigentlich benötigt, sind relativ gering. Verliert man jedoch den Fokus und fügt ein Feature nach dem anderen hinzu, so steigen die Kosten (Zeit und Geld), aber auch die Komplexität enorm an. Will der Kunde diese Features und ist bereit, dafür Geld zu bezahlen? Unnötige Komplexität führt letzten Endes auch zu unnötig hohen Aufwänden bei Betrieb und Wartung: Das Leben des Softwareentwicklers wird unnötig erschwert.

Für den Softwareentwickler lässt sich folgende Lehre aus dem Pareto-Prinzip ziehen: Er muss sich die Frage stellen: „Welche Funktionalität muss vorhanden sein, um das Ziel optimal zu erfüllen?“ Und darauf sollte er sich konzentrieren.

Die interne Kunden-Lieferanten-Kette (Kollegen als Kunden)

Ein Softwaresystem besteht aus einer Vielzahl von Technologien, Komponenten und Schnittstellen. An der Realisierung des Systems sind unter anderem mehrere Unternehmen beteiligt. Aus diesem Grund muss in der Softwareentwicklung auf die Vorleistung anderer aufgebaut werden. Die erstellten Artefakte (Frameworks, APIs etc.) werden von anderen Abteilungen, Teams bzw. Entwicklern genutzt oder Partnerunternehmen etc. bereitgestellt. Der Softwareentwickler ist also einerseits Kunde: seine Anforderungen z. B. an ein Framework sollen ihm bei der Lösung seines Problems (optimal) unterstützen. Und gleichzeitig Lieferant: seine Implementierung gegen das Framework soll die Anforderungen seiner Kunden erfüllen. Als Kunde erwartet er ein Produkt (Artefakt), das ihm bei der Realisierung seines Problems einen Nutzen stiftet. Nach der Fertigstellung seines Produkts geht es dann zum jeweils nächsten Glied in der Kette. Jeder „Kunde“ dieser Kette stellt wiederum Ansprüche, um seine Arbeit zu erleichtern. Deshalb muss der Fokus auf dem liegen, was im Moment gebraucht wird und einen Nutzen stiftet. Marketing!

So z. B. bei der Entwicklung eines API. Joshua Bloch, u. a. Entwickler des Java-Collections API, rät, nur Methoden in ein API aufzunehmen, von denen man sicher ist, dass sie benötigt werden und dementsprechend einen Nutzen generieren. Methoden, für die man noch keine Verwender kennt, sollte man nicht in das API mit aufnehmen: „If in doubt, leave it out“ [4]. Neues kann man leicht hinzufügen, Bestehendes aber nicht ändern bzw. entfernen, da man unter Umständen die Verwender nicht kennt. Man muss sich darauf fokussieren, die Anforderungen optimal zu erfüllen. Ansonsten wird die Komplexität des Systems unnötig erhöht. Was zur Folge hat, dass aufgrund neuer Kundenanforderungen größere Refactorings und damit auch größere Aufwände nötig werden.

Gerade in der Anwendungsentwicklung ist das Ausnutzen von Polymorphie, Design-Patterns, Testabdeckung, die Bereitschaft zur Selbstkritik und vor allem das Streben, sich ständig selbst zu verbessern (refactoring und bad smells [5], neue Methoden), essenziell für die strukturelle Qualität des Codes. Aber auch die funktionale Qualität (Funktionalität, Fehlerfreiheit) muss den Ansprüchen bzw. Anforderungen genügen. Und am Ende der Kette muss innerhalb des Zeitrahmens ein Produkt (Artefakt) bereitgestellt werden, das die Anforderungen bzw. Bedürfnisse erfüllt: Marketing!

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.