Wie man Software-Entwicklung aus den Augen verliert

Auf den Konferenzen im IKT-Bereich, bei denen Lösungen für bessere und effizentere Anwendungsentwicklung angeboten werden, gibt es grob gesprochen zwei Arten von Räumen: Einen, in denen IT-Entscheider mit den neuen, wunderbaren Paradigmen wie Prince2, Hermes, agiler Softwareentwicklung unterhalten werden und einen, in denen IT-Entwickler, Produktvertreter von SAP oder Perl-Hacker Schönheit und Features von Quellcode beäugen.

Auffällig ist, das Besucher der einen Veranstaltungsart fast nie im anderen Raum zu finden sind. Ein Buchhalter lernt ja auch nicht, mit dem Schraubenschlüssel umzugehen, werden einige jetzt sagen. In der Software-Industrie sind aber beide Tätigkeiten, Projektmanagement und Produktdesign, komplexe voneinander abhängige Tätigkeiten, gerade bei aufkommenden offenen Architekturen hoher Qualität.

Der Mythos der vernünftigen Arbeitsteilung …

Strukturierte Abläufe und Abstraktion sind starke abstrakte Prinzipien, die natürlich auch bei Software-Projekten gelten. Es fällt jedoch auf, dass alle paar Jahre “neue” Ansätze verkauft werden, wie ein Datenbanktool entwickelt werden sollte, wie eine Versicherungsapplikation geschrieben werden sollte. Das Niveau von Controlling und Leistung durch gute Kommunikation ist bereits merklich gestiegen. Trotzdem liegen Projektleistung und Qualität von einer Abteilung zur anderen weit auseinander.

… die Realität und ihre Folgen

Ein Hersteller eines renomierten Billingsystems hatte nach Qualitätsprüfung des Codes unterirdisch schlechte Werte. Der Abnehmer der Systeme war aber schon derartig “am Haken”, dass er auf fortwährende Optimierungen und massives Debugging angewiesen war. Hier hat sich das Geschäftsmodell “produziere Code mit heisser Nadel und versetze den Kunden in eine strategische Abhängigkeit” für eine Seite ausgezahlt. Selbst ohne Böswilligkeit bzw. unkluger langfristiger Planung ist Software-Design für den Auftraggeber oft Glücksspiel. Eine Marketingabteilung denkt, es sei normal oder findet sich damit ab, dass eine Blaufärbung eines grünen Buttons mit 2 Manntagen veranschlagt wird; ein freier IT-Berater stellt an einem Tag eine stabile Software auf die Beine, die Microsoft in Mannmonaten nicht hätte entwickeln können.

Zu oft werden hier Planungs- und Leitungsfehler unterstellt, während die Ingenieursseite, welche die eigentlich Innovation aus den Ideen der Auftraggeber in die Realität überführt, unterbelichtet bleibt. Die Finanzkrise krankte an undurchschaubaren Finanzprodukten, die keiner mehr verstand und jene, die sie verstanden, profitierten vom Unverständnis der anderen. Codier-Dummheit ist oft genauso gut in Zertifizierungen, Diplomen und TÜV-Auszeichnungen eingepackt. Es ist wert zu prüfen, welchen Einfluss das eigentliche “Hacking” auf Hack-produkte, sprich Software, hat.

Top-Ten typischer Codierungs-Mängel

Argumentativ ist es schwer, neben der Kodier-Qualität andere signifikante Einflussfaktoren “guter” Software zu sehen. Dies gilt umso mehr für Querschnitts-Aufgaben, die definitonsgemäß keine neue Zeile Code definieren oder hinzufügen. Verbesserungen von oben über moderne Managementansätze, sehen Codierung als Black-Box und optimieren über Dokumente (Spezifikationen) und Gruppenkoordination (z.B. tägliche Meetings). Verbesserungen von hinten über nachgelagerte QA-Abteilungen sehen Codierung als Küche und optimieren als Restauranttester über schnelle Entwicklungsschleifen und Debugginganstöße. Die Business-Seite sieht oft die gesamte IT-Abteilung als undurchschaubaren Lieferant und optimiert durch Marketing, Schulung und Verträge den Nutzen für sich.

Werfen wir einen Blick in die schwarze Schachtel guter oder schlechter Software-Entwicklung:

<Bild: Anteil der Codierungsqualität an der Projektqualität>

1. Fehler aus Datentypen
2. Fehler wegen Overflows
3. Scope-Fehler und andere Seiteneffekte
4. Redundanzfreiheit vs. Copy&Paste
5. Nichtbeachtung von Style-Guides
6. Nichtbeachtung von Software-Architekturen
7. Schlechte Team-Vorgaben für Entwickler
8. Wunschfehler: Obfuskation
9. Wunschfehler: strategische Abhängigkeit
10. Wunschfehler: Fresh-outs und Offshoring

Fazit

Gute Software ist als Innovationsleistung zumeist kein Produkt dicker Investitionen, sondern ambitionierter und disziplinierter Köpfe. Lassen wir einmal weg, das Kunden oft nicht wissen, was sie letztendlich möchten und einige Häuser aus taktischen Gründen nicht gut sein wollen oder müssen. Dann bleibt immer noch im interdisziplinären Zusammenspiel zwischen Kunde, Projektleitung, QA-Abteilung und Programmierer Letzterer in seiner kleinen Welt alleingelassen.

Rennfahrer müssen nicht verstehen, wie ein Motor aufgebaut ist – Michael Schuhmacher kann sich aber stundenlang mit Technikern unterhalten und im Zusammenspiel das Optimum aus dem Team herausholen.