Kommunikationsstruktur sticht Architektur

Wer definiert die Architektur?
 M.C.Escher: "Relativiteit", Juli 1953

Quizfrage: Wer hat den größten Einfluss auf die Architektur einer Software?

• Die Enterprisearchitekten, die organisationsweite und softwaresystemübergreifende Entscheidungen treffen (wie z.B. die Einführung von SOA im gesamten Unternehmen)?
• Die Solutionsarchitekten, die die Architekturentscheidungen für applikationsübergreifende Softwaresysteme treffen (wie z.B. die Verwendung von Domain-Driven Design)?
• Die Applikationsarchitekten, die die Architektur der einzelnen Applikationen definieren (wie z.B. die Verwendung von Hibernate für den Zugriff auf die DB)?
• Die Entwickler, die die Architektur schlussendlich umsetzen - potentiell anders, als durch alle vorangegangenen Architekten definiert?

Falsch geraten. Gemäß des Gesetzes von Conway hat die Kommunikationsstruktur der die Software umsetzenden Organisation den größten Einfluss auf die Architektur der Software.

Raumaufteilung und Projekterfolg

Kommunikationsproblem à Projekterfolg?
 Pieter Bruegel der Ältere 1563

Wie schon Frederick Brooks im "Mythical Man Month" feststellte, scheitern Softwareentwicklungsprojekte reihenweise an Kommunikationsproblemen. Klare Zielvorstellungen, genügend Personal, Zeit und Geld, sowie state-of-the-art Werkzeuge und Frameworks helfen genauso wie beim Turmbau zu Babel nichts, wenn die Kommunikation nicht passt. Kommunikationsprobleme sind die Hauptursache dafür, dass ein großer Teil der Softwareentwicklungsprojekte scheitern.

Was aber ist Hauptverursacher für Kommunikationsprobleme? In den wenigsten Fällen liegt es an den handelnden Personen. Der immer wieder zitierte ungepflegte, langhaarige, bebrillte, introvertierte Informatiker ist seit längerem so gut wie ausgestorben. In den meisten Fällen ist die ungeeignete Kommunikationsstruktur des handelnden Unternehmens für die Kommunikationsprobleme verantwortlich. Und diese wiederum ist abhängig von der räumlichen Aufteilung der Projektmitarbeiter.

Java Architekten im Elfenbeinturm und Maulwurfshügel

Was sieht man von dort oben?
 - peperoni -

Java Architekten nennen sich viele, doch werden sie auch wirklich ihrer Rolle gerecht? Die einen fühlen sich zuständig für die Definition der High-Level-Architektur sämtlicher Software, die in ihrem Unternehmen entwickelt wird. Sie nennen sich selbst "Enterprise Architekt", andere nennen sie "Theoretiker" und behaupten sie säßen im Elfenbeinturm. Andere wiederum definieren die detaillierte Architektur einzelner Applikationen, deren Schichten, Komponenten, interne und externe Schnittstellen sowie zu verwendende Frameworks. Sie nennen sich selbst "Systemarchitekt" oder "Applikationsarchitekt", andere nennen sie "kurzsichtig" und "technologiegeil" und behaupten, sie sehen die Aufgaben vor lauter Tools nicht.

Architekten laufen Gefahr abzuheben (die Architektur ausschließlich aus der 10.000 Meter = applikationsübergreifenden Perspektive zu betrachten) oder unterzutauchen (die Architektur ausschließlich aus der Maulwurfs = Framework Perspektive betrachten).

Nein liebe Enterprise Architekten, SOA, MDA, Cloud-Computing sind keine Architekturkonzepte die einfach so und überall funktionieren, und liebe Applikationsarchitekten, Spring, OSGi, JSF ... sind keine Architekturkonzepte und bringen in der Praxis oft mehr Nachteile als Vorteile. Dogfooding und ein bisschen mehr Reflexion über den tatsächlichen Nutzen ihrer Architekturentscheidungen würde vielen Architekten gut bekommen.

Was macht gute Modultests aus?

Hohe Code-Coverage - gute Qualität?
 Sebastian Dietrich

Gute Modultests (engl. Unit-Tests) können einen Großteil der Fehler finden, die sich während der Entwicklung eingeschlichen haben. Üblicherweise geht man davon aus, dass mit Modultests 80 - 90% aller Fehler gefunden werden können. Dies ist jedoch nur dann möglich, wenn diese Modultests (wie Regressiontests) laufend ausgeführt werden und eine ausgezeichnete Qualität aufweisen.

Limbo mit Softwarequalität

Limbo mit Softwarequalität?

Was tun, wenn die technische Qualität einer Software zu wünschen übrig lässt, aber kein Budget vorhanden ist, die Qualität zu verbessern? Unternimmt man nichts, so wird die Qualität weiter sinken - bis die Kosten für Wartung und Weiterentwicklung so hoch sind, dass die Software aufgegeben werden muss. Oft ist aber kein Budget vorhanden um die Qualität zu verbessern - diese Projekte ähneln Hungerkatastrophen - sie leben von der Hand in den Mund wohlwissend, dass sie bald verhungern werden, wenn nicht ein Wunder passiert. In dieser Situation hilft nur eines: Limbo mit Softwarequalität.

Schuldentilgung

Technische Schulden à Pleitegeier?
 Adrian Korte

Nimmt man in einem Softwareprojekt Technische Schuld auf sich, so könnte man versucht sein diese ähnlich zu betrachten, wie private finanzielle Schulden. Doch im Gegensatz zu privaten Schulden gibt es keine Konten auf denen die Technische Schuld beziffert wird, keine halbwegs fixen Zinssätze, die bei Aufrechthaltung der Schulden zu zahlen sind, keine Umschuldungen oder Schuldentilgungspläne. Im Gegenteil: Das Ausmaß der Technischen Schuld ist meist unbekannt, gleichzeitig zahlt man dafür Wucherzinsen.

Schuldhafte Softwareentwicklung

Viele kleine technische Schulden
 Public domain images

„Software zu schreiben ist wie Schulden aufnehmen. Geringe Schulden aufzunehmen beschleunigt die Softwareentwicklung, solange die Schulden rasch durch eine Neuimplementierung getilgt werden... Problematisch wird es, wenn die Schulden nicht zurückgezahlt werden. Jede Minute, die man mit nicht so gutem Code verbringt, zahlt man Zinsen für diese Schulden. Ganze Entwicklungsabteilungen können durch die Schulden unbereinigter Implementierung (egal ob objektorientiert oder nicht) zum Stillstand gezwungen werden.“

- Ward Cunningham zu Technischer Schuld, OOPSLA 1992

Wozu Java Zertifizierungen?

Oracle Certified Professional
 Sebastian Dietrich

Die besten Java Entwickler sind meist nicht zertifiziert. Das ist eine Tatsache, die unter Java Experten bekannt ist (umgekehrt gilt natürlich nicht, dass zertifizierte Java Entwickler schlechte Entwickler sind.). Dass so wenige Java Experten zertifiziert sind liegt vor allem daran, dass die Zertifizierungen erst aufkamen, als die meisten Java Entwickler schon viel praktische Erfahrung mit Java vorweisen konnten, und somit eine Zertifizierung für sie keinen Mehrwert darstellte.

Warum also sollten Java Entwickler eine Zertifizierung anstreben oder Manager ihren Mitarbeitern eine solche ans Herz legen? Dafür gibt es eine Reihe von Gründen - ob diese den Aufwand der Zertifizierung rechtfertigen, muss jeder selbst entscheiden:

Qualität von Softwareprojekten und Spaghetti

 Jenn Forman Orth

Softwareprojekte sind auch nicht anders als andere Projekte: Vor der (z.B. iterativen) Umsetzung der Anforderungen werden diese analysiert und z.B. in Form von Storycards oder Pflichtenheften oder Testfällen fixiert. Leider reicht das in der Praxis nicht, um damit die fachliche- und technische- (Wartbarkeit) Qualität zu definieren.

Wer im Rahmen von Softwareprojekten gute Qualität geliefert bekommen möchte, muss dasselbe beachten wie beim Kauf von Spaghetti (und allem anderen was käuflich ist):

Quality Gates bei Java Entwicklung

Quality Gates in der Softwareentwicklung
 Wikipedia

Die einzige Maßnahme, die die Qualität einer Software sicherstellen kann ist die Einführung von Quality Gates. Alle anderen "Qualitätssicherungsmaßnahmen" wie Pair Programming, Tests, Metriken etc. können die Qualität aufzeigen oder auch verbessern, aber niemals sicherstellen.

"Quality Gates sind Punkte im Ablauf eines Entwicklungsprojekts, bei denen anhand von im Voraus eindeutig bestimmten Qualitätskriterien über die Freigabe des nächsten Projektschrittes entschieden wird." - Jochen Peter Sondermann: Interne Qualitätsanforderungen und Anforderungsbewertung in Handbuch Qualitätsmanagement

"Freigabe des nächsten Projektschrittes" - das ist in der Softwareentwicklung die entscheidende Herausforderung.