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.

Warum ist Softwareentwicklung so teuer?

aus Tom DeMarco:
"Controlling Software Projects"
 Sebastian Dietrich

Softwareentwicklung ist meist weit teurer als anfänglich vermutet. Die Softwareentstehungskosten (Analyse, Design, Entwicklung, Test) machen nämlich in den meisten Fällen nur einen kleinen Teil der Gesamtkosten von Software aus. Betrachtet man die Kosten über den gesamten Lebenszyklus einer Software, so machen die Wartungskosten im Schnitt rund 2/3tel der Gesamtkosten von Softwareprojekten aus.

Funktionierende Software != Geringe Wartungskosten.

Java ist die Zukunft! Ist Java die Zukunft?

Java ist inzwischen mehr als 15 Jahre alt - ein nicht gerade jugendliches Alter für eine Programmiersprache. Inzwischen wird Java an jeder Informatik-HTL, -FH und -Hochschule gelehrt, was für einige ein deutliches Zeichen dafür ist, dass Java total veraltet sein muss.

Es gab und gibt Entwickler, Abteilungsleiter, Vertriebsmitarbeiter, etc., welche aus den einen oder anderen Gründen Java bereits den Tod nachsagten oder aktuell nachsagen - passend zum Kometenlied: "Java gibts auf kein’ Fall mehr lang."

Doch wie sieht die Realität aus?
Zahlt es sich aus in Java zu investieren, neue Projekte mit der alten Programmiersprache anzufangen, Zertifizierungen zu machen, Java Frameworks zu lernen, ....? Dazu gibt es neben den ohnedies bekannten SUN/Oracle Verlautbarungen (9 Mio. Java Entwickler, 3 Mrd. Geräte auf denen Java läuft) zwei mir bekannte Indices:

Joinvision 01/2007 - 01/2012

Tiobe Index 06/2001 - 01/2012

• Joinvision: Ein Jobportal für Freelancer und IT Fachkräfte für den deutschsprachigen Raum. Vergleicht die Häufigkeit bestimmter Schlüsselwörter in ihren Jobangeboten. Aktuell über 20.000 Jobangebote.
• Tiobe Programming Community Index: Vergleicht Programmiersprachen anhand ihrer Hits bei den wichtigsten 9 Webseiten mit Suchfunktion (Google, Blogger, Wikipedia, YouTube, Baidu, Yahoo, Bing, Amazon). Siehe Tiobe Index Definition.

Betrachtet man die Statistiken kommt man zu folgenden Erkenntnissen:

Java Konferenzen 2012

Auch heuer gibt es zum Thema Java wieder eine Menge Konferenzen. Wie jedes Jahr finden die meisten Konferenzen im Frühjahr (Februar - Juni) und im Herbst (Oktober - November) statt.

Folgende Termine und Preise konnte ich bisher ausfindig machen (Vermutungen in Grau):

 Gianfranco Chicco

• Februar: Jfokus (13.-15.2. Stockholm, SEK 6.995 (~ € 790) für drei Tage), Spring I/O (16.-17.2. Madrid) 
• März: TheServerSide Java Symposium (Las Vegas), EGJUG (9.-10.3. Kairo), EclipseCon (26.-29.3. Reston)
• April:  JAX (17.-19.4. Mainz € 1.429 für die dreitägige Konferenz), JavaOne (4.-5.4. Tokyo, 10.500 ~ € 106; 17.-18.4. Moskau), Devoxx (18.-20.4. Paris, € 350 für die zweitägige Konferenz)
• Mai: JavaOne (3.-4.5. Hyderabad, 4.500 Rupien ~ € 65 für die zweitägige Konferenz), Confess (7.-9.5. Leogang, € 300 für die dreitägige Konferenz), GeeCon (16.-18.5. Poznań, € 150 für die zweitägige Konferenz)