Softwareentwicklung ist eine anspruchsvolle Disziplin, die auf Millionen von Parametern, Variablen, Bibliotheken und mehr aufbaut. Ein Fehler genügt dabei, um den ganzen Stack zum Einsturz zu bringen. Und das ist nur die technische Seite. Rechthaberische Developer, anspruchsvolle Stakeholder, geizige Buchhalter und Meeting-affine Manager erzeugen in Kombination auch einen politischen Layer, angesichts dessen Ausformungen man sich manchmal fragt, wie das ganze Konstrukt überhaupt funktionieren kann. Im Laufe der Jahre haben Softwareentwickler beziehungsweise Dev-Teams jedoch stets neue innovative Wege, Methoden und Ansätze gefunden, ihre Tasks zu erledigen und die Grundlage für geschäftlichen Erfolg zu liefern.

Dennoch gibt es auch Dinge, die so gut wie jedes Softwareprojekt krachend scheitern lassen: die sieben Todsünden der Softwareentwicklung.

Keine Zeit zu lesen? Klicken Sie sich einfach im Schnellverfahren durch unser Development-Laster-Septett:

1. Falsche Methodik wählen

Jede Softwareentwicklungsmethode hat ihre Fürsprecher, die sich leidenschaftlich den jeweiligen Regelwerken unterwerfen. Ein Problem entsteht dabei oft dann, wenn es darum geht, die richtige Methode für das jeweilige Team zu wählen.

Wird die Methodik von oben auferlegt, während die Programmierer von einem anderen Ansatz überzeugt sind, wird das (mindestens) für anhaltende Unzufriedenheit sorgen. Den Programmierern in der Praxis freie Wahl zu lassen, ist allerdings auch nicht empfehlenswert, weil diesen unter Umständen der Blick dafür fehlt, welche Methodik für das gesamte Team am besten ist.

Die richtige Methodik zu wählen, löst nicht automatisch sämtliche Probleme. Aber es verringert Reibungsverluste, die durch die Workflow-Organisation entstehen.

2. Skalierbarkeit ignorieren

Einige Probleme im Bereich der Softwareentwicklung lassen sich im Nachgang beheben. Das gilt leider nicht, wenn eine effizient skalierende Anwendung entwickelt werden soll, die Millionen von Ereignissen verarbeiten kann. Effektiver Code erfordert viel Voraussicht - und Führungsstärke. Dinge, die sich eben nicht später mit ein paar Modifikationen und virtuellem Klebeband beheben lassen.

Algorithmen und Datenstrukturen brauchen Planung. Die zuständigen Softwarearchitekten und die Management-Ebene müssen also sorgfältig abwägen, welche Daten für jeden Benutzer gespeichert und verarbeitet werden sollen. Dabei spielt insbesondere auch eine Rolle, wie sich mögliche Lastspitzen auffangen lassen. Die architektonische Planung bringt manchmal jedoch auch mit sich, eigentlich gute Ideen verwerfen zu müssen. Hierbei gilt es für die Management-Ebene, Kosten und Nutzerwert von Funktionen mit Blick auf das große Ganze abzuwägen.

3. Trends verfallen

Softwareentwickler sind dafür bekannt, von neuen Ansätzen und Trends angezogen zu werden - neue Datenbanken oder Programmiersprachen stehen kontinuierlich hoch im Kurs.

Das Interesse an Innovationen hat auch durchaus seine Berechtigung. Das kann allerdings auch die eigentliche Entwicklungsarbeit lähmen oder sabotieren, wenn neue Technologien vorschnell produktiv eingesetzt werden. In manchen Fällen werden dabei Fehler oder Sicherheitslücken erst im Nachhinein bekannt. Ist das kurz vor der Projekt-Deadline der Fall, sind die Probleme meist gewaltig.

Vorsicht walten zu lassen ist deshalb bei respektive vor der Implementierung neuer Technologien oft die beste Maßnahme. Es hat auch einen Grund, warum einige der größten und ältesten Unternehmen noch immer mit Software arbeiten, die in COBOL geschrieben ist.

4. Daten horten

Programmierer weisen des Öfteren einen Hang zur Sammelwut auf. Viele speichern Informationen im Zweifel lieber ab - für den Fall, sie in der Zukunft noch einmal zu benötigen. Das kann jedoch sowohl aus Datenschutz- als auch aus Security-Perspektive problematisch werden. Ganz besonders, wenn es sich dabei um persönliche beziehungswiese besonders geschützte Daten handelt.

Zu einer guten Softwarearchitektur gehört auch eine vorausschauende Planung, was die Menge der gespeicherten Daten angeht. Diese weitmöglichst zu minimieren, schützt alle Beteiligten und kann darüber hinaus Storage-Kosten sparen und die Systeme beschleunigen, weil auch weniger Daten in Bewegung sind.

5. Falsch auslagern

Die Debatte darüber, ob es besser ist, Software zu kaufen oder selbst zu entwickeln, tobt schon seit einigen Jahrzehnten. Dabei treffen sowohl Entwickler als auch ihre Manager regelmäßig schlechte Entscheidungen. Erstere sind beispielsweise unter Umständen nicht bereit, ihre eigene, interne Lösung zugunsten einer günstigeren externen aufzugeben. Letztere lassen sich von Anbietern aufs Glatteis führen, kaufen ganze Produktlinien ein und müssen dann aufgrund langfristiger Vertragsbindungen tatenlos zusehen, wie die Preise kontinuierlich angehoben werden.

Leider bleibt die Entscheidung darüber, welche externen Tools verwendet werden sollen und welche nicht, eine fortwährende Herausforderung für beide Seiten.

6. Testing meiden

Effektive Softwareentwickler wissen: Testing ist das A und O. Unit- und Integrationstests sind unerlässlich, um sicherzustellen, dass der Code während des gesamten Entwicklungsprozesses funktionsfähig bleibt. Testing ist aber auch mit Blick auf große Workloads wichtig. Code für einen einzelnen Benutzer zu schreiben ist relativ simpel. Gibt es hunderttausend User, sieht die Sache ganz anders aus. Dann muss der Code effizient laufen und ein Large-Scale-Deployment ermöglichen.

Etliche Teams setzen auf Quality-Assurance-Tester. Das ist in manchen Fällen auch unerlässlich - ganz generell dann, wenn die Use Cases so komplex werden, dass es für einen einzelnen Entwickler zu diffizil wäre, sämtliche mögliche Variationen zu durchdenken und Code zu schreiben, der das entsprechend abdeckt.

7. Planung vernachlässigen

Programmcode erfordert in den meisten Fällen eine gewisse Hingabe an Planungsaktivitäten - was der Natur vieler Developer zuwiderläuft, die einfach nur möglichst schnell loslegen wollen. Pläne zu erstellen mag mühsam erscheinen, allerdings lassen sich Ideen mit abstraktem Denken oft wesentlich schneller austesten.

Planung bedeutet auch, die anderen beteiligten Teams und Stakeholder miteinzubeziehen. Sie sind diejenigen, die den Code in Zukunft nutzen werden. Die Zeit zu investieren, um ihre Bedürfnisse und Anforderungen kennenzulernen, kann im Projekt extrem viel Frustration ersparen.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.