10 Ursachen

Warum Software-Projekte länger dauern als erwartet

Kommentar  28.09.2020
Von 
Peter Wayner schreibt unter anderem für unsere US-Schwesterpublikation InfoWorld.com und ist Autor verschiedener Bücher - unter anderem zu den Themen Open Source Software, autonomes Fahren und digitale Transaktionen.
Dass Software-Projekte den anvisierten Zeitrahmen sprengen, ist normal. Jedenfalls nach Einschätzung des langjährigen Programmierers Douglas Hofstadter. Zehn Faktoren spielen eine Rolle.
  • Die zehn Punkte kreisen teils um Probleme mit den Daten selbst, teils um Intervention durch Anwender oder Manager aus dem Business
Software-Projekte werden nicht schneller fertig, wenn die Entwickler durch ständige Anfragen und Änderungswünsche unterbrochen werden.
Software-Projekte werden nicht schneller fertig, wenn die Entwickler durch ständige Anfragen und Änderungswünsche unterbrochen werden.
Foto: Syda Productions - shutterstock.com

"Ein endloses geflochtenes Band" - so betitelt Douglas Hofstadter sein Werk "Gödel, Escher, Bach". Er setzt darin die mathematische Arbeit Kurt Gödels zu den Illustrationen M. C. Eschers und der Musik Johann Sebastian Bachs in Bezug. Der Schlüssel liegt in Informatik und Molekularbiologie. Nach langen Jahren als Programmierer zieht Hofstadter folgendes Fazit: "Es dauert immer länger, als du denkst."

Denn auch Software-Projekte können endlosen Flechtbändern ähneln. Projekt-Manager und Stakeholder mögen mit den Fingern auf den Konferenztisch trommeln. Doch es gibt zehn Faktoren, die den Abschluss eines Projektes verzögern. Im Einzelnen:

1. Die Aufgaben ändern sich komplett: Es kommt vor, dass von einem Projekt nur noch der Name übrig bleibt. Das übergeordnete Unternehmensziel mag dasselbe sein - aber die konkreten Anforderungen an dieses Projekt ändern sich so stark, dass man ehrlicherweise besser davon sprechen solle, man habe ein neues Projekt gestartet, während das ursprüngliche eingeschlafen ist.

2. Zu wenig oder zu viel Beratung: Trotz all der Besprechungen und Meetings im Vorfeld - die manchem Entwickler übertrieben scheinen - fehlt es erstaunlich oft an der Vorabklärung einer Frage: wie soll das Software-Design aussehen? Selbst in einfachen Software-Projekten wird etwas Neues entwickelt. Kodieren ist keine Tätigkeit wie Straßenbau. Es läuft nicht immer gleich ab.

Für Business-Manager dreht sich alles um Prozesse

3. Die Grenzen agiler Methoden: Für Business-Manager dreht sich alles um Prozesse. Deshalb schwören sie auf Frameworks und Methoden. Agile Methoden sind besonders beliebt, weil sie viel Freiheit bieten - genau das aber kann im Chaos enden. Mancher Manager denkt, wenn der Code nicht passt, macht man eben ein neues Ticket auf. Doppelt so viele Tickets bringen aber weder doppelt so viel Anerkennung noch doppelt so viel Leistung.

4. Keiner blickt weit genug voraus: "Wenn ich weiter sehen konnte, so deshalb, weil ich auf den Schultern von Riesen stand", schrieb Isaac Newton in einem Brief an Robert Hooke. Dem durchschnittlichen Software-Entwickler stehen diese Riesen aber nicht zur Verfügung. Trotzdem soll er etwas mit "Disrupt"-Potenzial programmieren, das gleichzeitig noch supercool aussieht.

5. Interessenvertreter ändern ihre Meinung: Seien es die Endverbraucher oder Stakeholder innerhalb des Unternehmens - viele Interessenvertreter reden direkt oder indirekt bei Software-Projekten mit. Plötzlich müssen die Entwickler weitere Wünsche berücksichtigen oder ihre bisherige Arbeit verändern. Das lässt sich in manchen Fällen problemlos erledigen. In anderen macht es vieles zunichte.

6. Die Daten und ihre Strukturen: Sind die Datenbanken komplett und akkurat? Auf ihnen basieren die Datenmodelle. Daten müssen in Strukturen gebracht werden - zum Beispiel in Felder für Postleitzahlen, die eine bestimmte Zeichenzahl nicht überschreiten dürfen. Was, wenn dann Geschäftspartner einbezogen werden sollen, deren Postleitzahl aus einer Kombination von Ziffern und Buchstaben bestehen? Es bleibt ein Dilemma zwischen Strenge und Flexibilität.

Mit Beginn der Sommerzeit hat der Tag keine 24 Stunden

7. Falsche Annahmen: "Jeder Tag hat 24 Stunden." Dieser Aussage wird niemand widersprechen. Bis auf den Programmierer, der plötzlich mit dem Beginn von Sommerzeit und Winterzeit zu tun hat.

8. Komplexität: Programmierer hätten gern geradlinige Systeme, aber Anwender wünschen noch dieses oder jene Feature zusätzlich. Doch jede weitere Spalte in der Datenbank und jeder weitere Layer im Code bedeuten mehr Komplexität.

9. Design-Prüfungen: Das Design zu überprüfen, ist unverzichtbar. Dabei ist jedem Programmierer bewusst, dass jede Review dazu führen kann, dass Code neu geschrieben werden muss. Dieses Problem wird sich nie lösen lassen. Dennoch: Es gehört zu einem sauberen Entwicklungsprozess, das Feedback der Anwender einzubeziehen.

10. Ein Hoch auf die Langsamkeit: Die launische Natur der Software-Projekte ist kein Bug, sondern ein Feature. Coding ist eine wichtige Arbeit, die ihre Zeit braucht. Am besten, man lässt die Software-Entwickler ungestört arbeiten.