Zehn Grundthesen zur erfolgreichen Software-Entwicklung

Jahrzehnte meines Berufslebens war ich als Entwickler von Software-Produkten tätig, einen großen Teil davon als Projekt- oder Bereichsleiter. Ich habe viel über meine Erfahrungen veröffentlicht, sowohl in Fachartikeln wie auch in Büchern. Ich gab Kurse an Hochschulen und in Unternehmen. Immer wieder werde ich daran erinnert, dass es sinnvoll sein könnte, meine Erfahrungen und Überlegungen in der Form weniger Grundthesen zusammenzufassen. Hier ein neuer Versuch. Ich setze einige Fachkenntnisse voraus. Dass manche Formulierungen überspitzt klingen, ist Absicht. Auch kürze ich brutal. Ich möchte Leserinnen und Leser persönlich ansprechen, duze sie jedoch nicht.

1. Denken Sie zu allererst und immer wieder an Nutzerinnen und Nutzer

Software-Produkte oder Software-Dienste wollen genutzt werden. Wenn Sie sich keine Nutzer vorstellen können, vergessen Sie das Projekt so schnell wie möglich. Wenn Sie selbst ein typischer Nutzer sind, hat dies große Vorteile. Erfahrene Entwickler wundern sich oft, wenn sie sehen, wie Nutzer sich anstellen. Ein Kollege, der dies nicht länger aushalten wollte, änderte die Benutzerschnittstelle über Nacht. Alle Versuche Nutzerfähigkeiten oder Nutzerverhalten individuell oder zeitlich zu analysieren und zu differenzieren sind unbeliebt. Nutzer lernen und passen sich an, soweit die Anwendung dies wert ist. Das ist ihnen weitaus lieber, als dass das System individuellem Verhalten nachspürt.

2. Gute Methoden und Werkzeuge sind wichtig

Nicht alle Methoden sind für alle Projekte gleich gut geeignet. Vergleichbare Methoden über mehrere Projekte hinweg zu verwenden, erlaubt eine schrittweise Verbesserung ihrer Beherrschung. Werkzeuge dienen der Unterstützung von Methoden. Das Vorhandensein oder Nicht-Vorhandensein von guten Werkzeugen begünstigt bzw. benachteiligt gewisse Methoden. Ja, es beeinflusst, welche Probleme man gerne oder weniger gerne angeht. Es gilt der Spruch: Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel. Die Informatik neigt dazu, Methoden-Gurus anzuhimmeln, auch an Hochschulen. Typische Beispiele sind formale und agile Methoden.

3. Produktivität der Entwicklung ist uninteressant

Wer Entwickler an ihrer Produktivität misst, verrät damit nur Unkenntnis oder Missachtung  dieser Tätigkeit. Entscheidend ist der Wert des Arbeitsergebnisses. Ein sinnvolles Maß ist die Kapitalrendite (engl. return on investment, Abk. ROI). Oft ist auch die Entwicklungszeit wichtig (engl. time to market). Bei der Software-Engineering-Tagung 1969 in Rom hatte Tom Simpson (damals IBM Wheaton, MD) einen Beitrag mit dem Titel "Masterpiece Engineering" eingereicht. Er passte den Veranstaltern nicht ins Konzept. Er wurde daher nur vor Ort verteilt und nicht veröffentlicht. Simpson hatte darin die damals gerade aufflammende Debatte über Entwickler-Produktivität persifliert. Sie käme ihm vor, wie wenn man Michelangelos Leistung mit Meißelschlägen oder Pinselstrichen pro Tag messen würde.

4. Preis- und Geschäftsmodelle gibt es unzählige

Kaufleute sind nicht weniger kreativ als Ingenieure und Informatiker. Ihre Domäne ist nicht gute Technik, sondern gute Preis- und Geschäftsmodelle. Ohne sie taucht die beste Technik nichts. Die oben erwähnte Kapitalrendite (ROI) interessiert nicht immer. Jeff Bezos von Amazon z. B. arbeitet seit Jahren primär an der Vergrößerung seines Marktanteils. Um Gewinne zu machen, lässt er sich viel Zeit. Gewinn ist Ertrag minus Kosten. Es ist ein großer Unterschied, über welchen Zeitraum man rechnet, etwa Quartale, Jahre oder Jahrzehnte. Was gilt als Kosten? Was zählt als Ertrag? Da gibt es viel Spielraum. Bei Software geht der Grenzwert der Kosten gegen Null, d.h. die n+1te Kopie kann umsonst sein, wenn die ersten n Kopien bereits die fixen Kosten hereingespielt haben. Erträge können durch den Verkauf des Produkts selbst erzielt werden, oder auf viele andere Arten.  In der Frühzeit unserer Branche stand der durch Software ermöglichte Hardware-Umsatz im Vordergrund, heute ist es meist der Werbeumsatz. In den USA konnte in den letzten Jahrzehnten auch für nicht-technische Erfindungen (engl. business methods) Patentschutz beantragt werden. Zurzeit wird wieder stärker die Technizität einer Erfindung beachtet.

5. Lebendigkeit des Produkts oder Dienstes ist essentiell

Mit dem Wort Lebendigkeit beschreibe ich zwei verschiedene Eigenschaften eines Software-Produkts oder Software-Dienstes. Der Nutzer empfindet ein Produkt als lahm und störend, sofern es nicht innerhalb von etwa 100 Millisekunden auf seine Eingabe reagiert. Genau genommen, ist es eine Verteilungskurve mit einem Schwanz. Ausreißer müssen aber erklärbar sein. Eine zweite Form von Lebendigkeit drückt sich darin aus, dass ein Produkt sich in der Interaktion mit der Nutzerschaft ändert. Es reagiert im Verlaufe der Nutzungszeit auf Änderungen im Anforderungsprofil.

6. Sie können es lernen Qualitäts-Software  zu entwickeln 

Über schlechte Software zu schimpfen ist populär. Pauschale Aussagen sollte niemand ernst nehmen. Gute Software zu entwickeln ist möglich, aber schwierig. Ernsthafte Entwickler und Entwickler-Teams lassen sich nicht von Gurus verführen. Sie lernen am meisten aus den eigenen Fehlern. Das geht nicht auf einen Schlag, sondern erfordert Geduld. Es ist ein Prozess, der Jahre in Anspruch nimmt. Fehlerfreiheit ist ein wichtiges, aber nicht das einzige Qualitätskriterium von Software. Ohne marktrelevante Funktionalität bleibt Software ungenutzt.

7. Fehler gibt’s ganz unterschiedliche und alle wollen gesucht sein

Jeder Fehler ist eine Abweichung vom Soll. Nur wer das Soll kennt, kann Fehler identifizieren. Wer Fehler behandeln oder eliminieren will, muss differenzieren. Ein funktionaler Fehler ist etwas anderes als ein Sicherheits- oder Bedienungsfehler. Sie zeigen sich nicht alle gleichzeitig oder gleich leicht. Nicht alle Fehler melden sich von selbst. Man muss nach ihnen suchen. Die dafür geeigneten Methoden sind äußerst unterschiedlich. Es gibt kein universelles Hilfsmittel. Das gilt sowohl für die Vermeidung wie für die Aufdeckung von Fehlern, egal welcher Software-Theorie man anhängt. Entwickler sind dann schlecht, wenn es darum geht, eigene Fehler zu finden. Ein unbefangener Kollege ist meist erfolgreicher.

8. Minimiere die Lebensdauer von Fehlern

Ein Entwicklungsprojekt umfasst in der Regel unterschiedliche Tätigkeiten, so z.B. Anforderungsanalyse, Entwurf, Implementierung, Inspektion, Integration, Test, Installation, Verteilung, Betrieb, Wartung und Außerbetriebnahme. Die einen sind konstruktiv, andere sind analytisch. Bei jeder Tätigkeit können Fehler entstehen. Diejenigen, die in frühen Phasen eines Projekts entstehen, können am längsten wirken, es sei denn, sie werden früh eliminiert. Ein Fehler wird umso teurer, je länger er bestehen bleibt. Keine mir bekannte Methode zur Aufdeckung von Fehlern ist allumfassend. Durch Testen werden andere Fehler gefunden als durch Inspektionen. Korrektheitsbeweise sind nur so gut wie die benutzten Zusicherungen.

9. Machen Sie jeden gefundenen Fehlertyp zum letzten seiner Art

Alle Raumfahrtprojekte der NASA verdankten ihren Erfolg einer klugen Software-Strategie. Man korrigierte nicht nur die gefundenen Fehler, sondern suchte anschließend nach ähnlichen Fehlern sowie nach den gemeinsamen Ursachen. Will man nämlich bei zukünftigen Projekten die Wiederholung eines Fehlertyps vermeiden, so muss man denjenigen Teil des Prozesses verbessern, der für die Entstehung dieses Fehlers verantwortlich ist. Diese Vorgehensweise ist zwar sofort einleuchtend  ̶  nur Dummköpfe machen dieselben Fehler mehrmals  ̶  verlangt aber eine außerordentliche Disziplin. Dieser Ansatz funktioniert nicht, wenn man als Software-Entwickler nur kurzfristig auf einem Arbeitsgebiet tätig ist und nach Projektabschluss sich sofort in ein völlig fremdes Anwendungsgebiet stürzt. In diesem Falle müssen andere Methoden angewandt werden, etwa die iterative Entwicklung von Prototypen. Das sind funktional eingeschränkte Vorabversionen. Auf vollkommen fehlerfreie Programme zu hoffen, ist nicht viel mehr als eine Utopie. Erreichbar ist dieses Ziel, wenn die Aufgabenstellung entweder allen Beteiligten von Vornherein bekannt ist, oder wenn die Programme nicht allzu groß sind. Die Grenze liegt etwa bei 100.000 Programmzeilen.

10. Fördere Forschung, die Entwickler inspiriert

Jeder Entwickler träumt davon, einige Probleme, die sich ihm in den Weg stellten, gründlich zu analysieren und eine optimale Lösung zu finden. Das ist aber nicht die Forschung, die bei uns größtenteils mit öffentlichen Mitteln finanziert, vorwiegend an Hochschulen betrieben wird. Wem das dabei generierte Wissen nützt, entgeht mir zu einem großen Teil. Nicht immer inspiriert sie Entwickler oder hilft ihnen weiter. Industrielle Forschung etwa bei IBM, Microsoft und SAP setzte erst ein, nachdem diese Firmen bereits Erfolg im Markt hatten. Wer Forschung mit Lernen gleichsetzt, sollte beachten, dass Ingenieure und Informatiker am meisten aus erfolgreichen Produkten lernen können. Dabei zählen eigene, aber auch die der Mitbewerber. Die üblichen Fachzeitschriften zu lesen, bringt Informatikern wenig.

NB.: Eine englische Version dieses Beitrags finden sie hier.