Java zu komplex?

Die Komplexität von Java habe ich in diesem Blog schon mehrfach angesprochen. Jetzt hält mein Ex-Kollege Niko Wulff dazu einen Vortrag auf der W-JAX 2007: Die Grenzen der Komplexität.

Und dann berichtet die Computerzeitung über einen Programmierwettbewerb namens Platforms, an dem unter anderem Teams in Java und PHP programmiert haben. Das Beste Team war ein Java-Team, aber die anderen beiden Java-Teams sind anscheinend an der Komplexität gescheitert. Die drei PHP-Teams hatten wohl durchweg gute Ergebnisse.

Das erinnert mich sehr an einen frühen Performancevergleich zwischen C++ und Java. Dort war das beste C++-Programm um Größenordnungen schneller als das beste Java-Programm. Allerdings waren die Java-Programme im Durchschnitt leicht schneller als die C++-Programme. Die Begründung ist einfach: Mit C++ konnte man viel performantere Programme schreiben als in Java. Allerdings muss man dafür soviel an Komplexität beherrschen, dass die meisten Entwickler mit C++ sehr langsame Programme geschrieben haben.

So hört es sich jetzt auch mit Java und PHP an: Mit Java kann man bessere Systeme schreiben als mit PHP. Allerdings können nur wenige Entwickler die Komplexität von Java so gut beherrschen, dass das auch gelingt.

Jetzt haben wir wahrscheinlich nur das Problem, dass alle Entwickler glauben, sie würden zu den wenigen gehören, die die Komplexität beherrschen. Die Statistik sagt aber was anderes. Die sagt: "Was auch immer Du denkst. Wahrscheinlich bist Du nicht in der Lage, die Komplexität zu beherrschen."

Daher mache ich hier mal den Anfang: Mich überfordert das ganze Zeugs rund um EJB, WSDL, SOAP, WS-*, JTA, JAAS, extends und super bei den Generics, geheimnisvolle Compilefehler rund ums Autoboxing, Abhängigkeitswirren bei Classloadern, etc. Natürlich kriege ich es letztlich dann doch ans Laufen. Aber die Zeit dafür würde ich lieber in die Entwicklung kundennützlicher Features investieren.

Post bewerten

WOMM Certification

Works On My Machine Certification

Muss man haben!

Post bewerten

Dämlicher Desktop

Als die ersten grafischen Benutzungsoberflächen auf der Bildfläche erschienen, war auch bereits der Desktop mit dabei. Auf ihm sollte man sich die Dinge anordnen, mit und an denen man gerade arbeitete. Das hat im großen und ganzen nicht funktioniert. Ich kenne niemanden, der das so macht. Eigentlich wird das Ding nur als überdimensionale Startleiste verwendet, in die man sich die Programme legt, die man häufig benötigt - und vielleicht noch Verknüpfungen zu Ordnern, die man oft braucht. Mache ich auch so. Ist ja auch nützlich.
Interessanterweise hat Windows eine Eigenart, die mir das Arbeiten mit dem Desktop verleidet. Wenn man die Bildschirmauflösung verändert, schiebt Windows die Icons auf dem Desktop so zusammen, dass sie noch alle angezeigt werden können. Das ist vernünftig. Richtig dämlich ist aber, dass die Originalanordnung nicht wieder hergestellt wird, wenn man die Originalauflösung wieder herstellt. Die Anordnung der Icons müsste abhängig von der Bildschirmauflösung gespeichert werden. Wird sie aber anscheinend nicht. Und leider hat sich das auch mit Windows Vista nicht verbessert.
Wenn man einen Desktop-Rechner hat, ist das wahrscheinlich nicht so schlimm. Aber wenn man sein Notebook auch für Präsentationen nutzt, schaltet man ständig die Auflösungen um und hat dann den Ärger.
Auf dem Mac ist das bestimmt besser gelöst, oder?

Post bewerten

Lastenheft vs. User Stories

Im Lastenheft beschreibt der Kunde, welche Aufgaben ein zu erstellendes Softwaresystem unterstützen muss. Anscheinend gewinnt es zur Zeit eine stärkere Bedeutung, insbesondere im Verhältnis zum Pflichtenheft - im Pflichtenheft beschreibt der Softwarehersteller, wie er die Software gestalten wird.

Diese höhere Bedeutung des Lastenheftes liegt vor allem an Kommunikationsproblemen zwischen Fachabteilungen und Softwareentwicklern. Die von den Softwareentwicklern geschriebenen Pflichtenhefte sind für Fachabteilungen größtenteils unverständlich und daher keine geeignete Basis für die Vereinbarung des zu entwickelnden Systems.

Genau dieses Kommunikationsproblem adressieren auch die agilen Methoden, aber mit anderen Mitteln als dem Lastenheft. Bei den agilen Methoden wird das statische Lastenheft quasi durch
einen Lastenheft-Generator ersetzt. Dieser Lastenhaft-Generator ist ein Mitarbeiter des Kundenund heißt ja nach gewählter Nomenklatur mal Kunde (XP) und mal Produktverantwortlicher (Scrum).
Dieser Produktverantwortliche hat die Aufgabe, jeweils soviele Anforderungen zu generieren, wie zur Zeit realisiert werden können. Er generiert das Lastenheft quasi während der Projektarbeit. Dabei wird auf persönliche Kommunikation zwischen Produktverantwortlichem und Entwicklern gesetzt, um Kommunikationsprobleme zu vermeiden.

Damit übertragen agile Vorgehensweisen die Prinzipien der Just-In-Time-Production auf die
Softwareentwicklung: Die Anforderungen sind genau in dem Moment definiert, in dem sie benötigt werden.

Die Vorteile dieser Vorgehensweise liegen auf der Hand: Es wird keine lange Vorlaufphase für
die Definition des Lastenhaftes benötigt. Man kann sofort mit der Softwareentwicklung beginnen, sobald der Bedarf entdeckt wurde. Der Produktverantwortliche kann auf veränderte Rahmenbedingungen sofort reagieren - er muss ja nicht massenhaft bereits definierte Anforderungen ändern. Die Kosten auf Kundenseite sinken, weil der Produktverantwortliche immer nur genau die Anforderungen definiert, die auch realisiert werden. Es wird kein Aufwand in die Definition von Anforderungen gesteckt, die dann doch nicht realisiert werden. Erste Versionen der Software kann der Produktverantwortliche begutachten, daraus lernen und die Generierung weiterer Anforderungen mit dem Gelernten abgleichen.

Allerdings ist diese agile Vorgehenweise nicht für alle Kunden sofort umsetzbar - genau so wenig, wie es der westlichen Industrie gelungen ist, Just-In-Time-Production vom einen Tag auf den nächsten umzusetzen. Die Problematik bei der agilen Softwareentwicklung liegt in der Rolle des Produktverantwortlichen. Es ist durchaus eine Herausforderung, die Anforderungen genau zeitgerecht (eben Just-In-Time) zu definieren. Generiert der Produktverantwortliche die Anforderungen zu langsam, hat das Entwicklerteam kostenpflichtigen Leerlauf oder muss mit undurchdachten Anforderungen arbeiten. Generiert der Produktverantwortliche die Anforderungen zu schnell, liegen sie auf Halde.
Je mehr Anforderungen auf Halde liegen, desto größer die Gefahr, dass ein Teil der Anforderungen gar nicht realisiert wird. In diesem Fall hat der Produktverantwortliche seine wertvolle Arbeitszeit umsonst investiert. Anforderungen auf Halde wären in der Nomenklatur der Just-In-Time-Production Verschwendung.

Die Definition und die Realisierung von Anforderungen im Fluss zu halten entspricht genau dem Flow-Gedanken aus dem Just-In-Time-Production. Die einzelnen Produktionseinheiten in eine Fabrik entsprechend einzustellen, heißt Production Leveling. Und genau diese Herausforderung besteht auch bei agilen Softwareprojekten.

Eine große Hürde ist dabei häufig die Organisationsstruktur des Kunden. Muss der Produktverantwortliche sehr viele Parteien einbeziehen, ohne dass es sehr klare Strukturen gibt, gleicht seine Aufgabe dem sprichwörtlichen Hüten von Flöhen. Es besteht ein hohes Risiko, dass ein ziemlich inkonsistentes System entsteht.

Tatsächlich mag in solchen Fällen das Lastenheft doch die bessere Variante sein. Das gilt
allerdings nur, wenn der Lastenheft-Autor auch ausreichend Zeit für all die Abstimmungen
zur Verfügung hat. Unter Zeitdruck erstellte Lastenhefte neigen zu undurchdachten Anforderungen. Da sie statisch festgeschrieben sind, ist der Kunde dann mit dem Lastenheft wiederum schlechter bedient als mit dem agilen Produktverantwortlichen.

Zwischen dem Produktverantwortlichen im Sinne von Scrum oder XP und dem klassischen Lastenheft gibt es aber auch Zwischenstufen. FDD liefert mit der vorgeschalteten gemeinsamen Modellierungsphase einen guten Ansatzpunkt. Das Projekt wird dabei in Abschnitte von maximal 6 Monaten unterteilt. Für jeweils einen solchen Abschnitt findet eine Upfront-Analyse/-Modellierung statt. Dadurch wird die Gefahr von Inkonsistenzen reduziert. Natürlich bezahlt man das, indem man nicht mehr so schnell auf neue Erkenntnisse reagieren kann, wie mit XP oder Scrum. Man ist aber immer noch schneller und leichtgewichtiger unterwegs als mit dem klassischen Lastenheft.

Post bewerten

Spargelzeit

Sauce Hollandaise

Post bewerten

XP-Day 2007

Die XP-Days 2007 finden dieses Jahr wieder in Karlsruhe statt und die Vorbereitungen laufen. Der Call-For-Sessions ist raus und es tut sich auch schon was auf dem Konferenz-Blog.

Post bewerten

Thinkpad T60

Während immer mehr meiner Bekannten mit Apple-Notebooks durch die Gegend rennen, hat sich meine Firma erstmal weiter auf Windows festgelegt. Also ist mein neues Notebook kein Apple, sondern ein Lenovo Thinkpad T60 mit Wide-Screen. Auf dem Papier schien er etwas breiter zu sein, als mein alter DELL. In echt wirkt er aber viel breiter. Naja, was soll's.

Ich habe den größeren Akku und die kleinere, aber schneller Festplatte einbauen lassen. Im Sparsam-Betrieb reicht der Akku knapp 5 Stunden - so lange wie beide Akkus beim DELL zusammen.

Die Tastatur fühlt sich beim Thinkpad etwas besser an als beim DELL. An Hardwarefeatures fällt zunächst mal der Fingerabdrucksensor ein, mit dem man sich anmelden kann, nachdem man etwas trainiert hat, wie man den Finger richtig über den Sensor zieht. Nettes Feature. Es dauert aber Ewigkeiten, bis ich mich mit dem Ding auch anmelden kann - ich habe bis heute nicht verstanden, wie ich das gemacht habe. Schneller als die Eingabe des Passworts ist die Anmeldung mit dem Sensor allerdings nicht - dazu ist die Fingerabdruck-Erkennung zu langsam.

Auf dem Thinkpad ist Windows Vista installiert. Es braucht leider eine Weile zum Hochfahren (mehrere Minuten, 25 Sekunden aus dem Sleep-Mode). Von der Bedienbarkeit zeigt Vista aber dann einen deutlichen Fortschritt gegenüber Windows XP. Es sieht besser aus (wahrscheinlich ist das alles bei Apple angeguckt - immer noch besser also schlecht selbst ausgedacht).
Besonders nützlich ist, dass man überall Suchfelder hat, um nach Programmen, Dateien und Verzeichnissen zu suchen. Wenn man ungefähr weiß, was man sucht, tippt man das ein und muss sich nicht mehr durch Verzeichnisse oder Menüs klicken.

Etwas verwirrt war ich am Anfang, weil das System die fest eingebauten Verzeichnisse mal englisch und mal deutsch anzeigt. Im Dateisystem heißt es z.B. "Programme". Wenn man Software installiert, sagt die, sie würde sich nach "Program Files" installieren, sie landet aber unter "Programme".
Wenn man einen Verzeichnispfad ins Clipboard keopiert und in ein Textfeld einfügt, erscheint auch der englische Name. Anscheinend heißt alles englisch und der Explorer übersetzt.

Die Software, die ich bisher verwendet habe, läuft auch auf Vista. Nur bei Eclipse muss man tricksen. Bei Vista darf man nicht mehr ohne Bestätigung ins Programme-Verzeichnis schreiben. Daher muss man Eclipse beim Start explizit sagen, dass die Config-Dateien an einem anderen Ort abgelegt werden müssen und neue Plugins muss man auch an einen anderen Ort installieren. Oder man installiert Eclipse nicht im Programme-Verzeichnis. Muss man halt nur wissen.

Zusätzlich zu den automatischen Windows-Updates ist auf dme Gerät das "Lenovo Produktivitätscenter" installiert. Das lädt z.B. automatisch Aktualisierungen des BIOS etc. Das ist doch auch mal nett.

Dummerweise ist das Lenovo-Produktivitätscenter nicht ganz kompatibel mit Windows Vista. Daher erscheinen seine Benachrichtigungsfenter nicht auf dem Desktop, sondern in einem Extra-Modus, auf den Vista ständig hinweist, wenn sich im Hintergrund das Produktivitätscenter geöffnet hat. Nach kurzem Notebookbetrieb schlägt das Produktivitätscenter vor, ein dutzend Aktualisierungen nachzuladen. OK. Die ganze Geschichte bleibt nach ein paar Stunden bei 77% Fertigstellung stehen. Also boote ich den Rechner neu. Danach zeigt das Notebook beim Login nicht mehr die Option für den Fingerabdrucksensor an. Es dauert eine Weile bis ich bemerke, dass man sich immer noch per Fingerabdruck anmelden kann. Hin und wieder kommt auch noch der alte Anmeldebildschirm. Und hin und wieder gibt die Fingerabdruck-Software einen "internal error" und stürzt ganz am Anfang ab. So richtig ausgereift wirkt das noch nicht. Mit der Zeit ist das Problem aber immer seltener aufgetreten.

Ich installiere die Software für die UMTS-PC-Karte. Im Internet bei Vodafone gibt es extra eine Version für Vista. Nach der Installation klappt mit der Karte auch alles super. Dafür gehen LAN und WLAN nicht mehr. Vista zeigt mit abwechselnd "lokaler Zugriff" und "eingechränkte Konnektivität für die beiden Netzwerk-Adapter an. Die Ursache scheint zu sein, dass ich jetzt mit "Nicht identifiziertes Netzwerk"
verbunden bin. Ich probiere der Reihe nach alle Problemlösungen aus, die Vista mir vorschlägt. Alles ohne Erfolg. Jetzt schlängt Vista mir vor, ONLINE nach einer Lösung zu suchen. Pfiffig...
Also deinstalliere ich das Vodafone-Zeug. Jetzt habe ich einen absolut sicheren Rechner. Ich kann mich mit gar nichts mehr verbinden :-(

Nach stundenlangem rumprobieren und mehrfachen Neustart meines Routers geht alles wieder. Ich installiere die Software für die UMTS-Karte. Es scheint immer noch alles zu funktionieren.

Ich fahre auf die JAX und bin wahrscheinlich der einzige Teilnehmer, der nicht ins dortige WLAN kommt. Woran es liegt, kann ich mit Windows Vista nicht herauskriegen. Der Rechner verbindet sich zwar mit dem WLAN, vom Internet kann ich aber nichts sehen. Also benutze ich halt die UMTS-Karte. Das WLAN im Hotel hingegen funktioniert.

Als ich wieder zu Hause ankomme, geht weder WLAN noch LAN - auch nicht nach mehrfachem Neustart von Rechner und Router. Ich bin echt genervt. Windows meint, dass wahrscheinlich LAN- und WLAN-Netzwerkadapter kaputt sind.
Ich suche bei Lenovo im Internet. Man soll beim Systemstart F11 drücken. Dann kommt ein Diagnose-Programm. Dort soll man "Hardwarediagnoe" auswählen. Den Punkt gibt es aber nicht, auch sonst nichts, was mir weiterhilft.
Also ermittle ich die Telefonnummer für den Support und stelle fest, dass der
in Deutschland nur Mo.-Fr. 8-16 Uhr besetzt ist. Die Franzosen haben es besser
mit 24*7-Support. Aber ich spreche kein französisch. Naja, man kann auch in
den USA anrufen. Da ist auch immer jemand da. Da habe ich aber keinen Nerv drauf. Also deinstalliere ich nochmal die Vodafone-Software und schon funktioniert es wieder. Scheint also doch an der Vodafone-Software zu liegen. Ich werde mal deren Support anrufen.

Auch ohne Vodafone-Software schaltet sich ab und an das WLAN des Notebooks ab. Keine Ahnung warum.

Fazit: Das Thinkpad ist leicht besser als mein alter Dell. Vista ist leicht besser als Windows XP. Richtig begeistern kann ich mich aber für beides nicht.

Post bewerten

FDD-Reisebericht: Features beschreiben und organisieren

Im Feature-Driven-Development werden feingranulare Features für Planung, Realisierung und Tracking verwendet. Dabei gilt, dass ein Feature maximal 2 Wochen Realisierungszeit benötigen darf. Meistens sind die Features aber viel kleiner (z.B. 1 Tag).

Interessant ist, dass FDD ein festes Beschreibungsschema für Features hat:

<Aktion> <Ergebnis> <Objekt>


So entsteht ein einfacher Satz wie "Berechne Summe der Auftragspositionen".

Damit man in großen Projekten die Übersicht nicht verliert, werden Features zu Feature-Sets zusammengestellt. Dabei empfiehlt sich eine feste Richtlinie, wie Feature-Sets gebildet werden. FDD schlägt für Geschäftsanwendungen vor, Feature-Sets nach Geschäftstätigkeiten zu bilden, z.B. "Auftragsannahme".

Hat man es mit sehr vielen Feature-Sets zu tun, werden diese wiederum in Major Feature-Sets gruppiert, wieder nach einer festen Richtlinie. FDD schlägt für Geschäftsanwendungen vor, Major Feature-Sets nach Geschäftsbereichen zu organisieren, z.B. "Einkauf".

In meinem aktuellen Projekt haben wir die Anforderungen auf das FDD-Schema umgestellt und damit einige positive Erfahrungen gemacht:

• Wir verwalten unsere Anforderungen in einem Issue-Tracker (Mantis). Der FDD-Satz bildet die Zusammenfassung der Anforderung. Dadurch sind i.d.R. die Zusammenfassungen in einer Übersichtsliste so aussagekräftig, dass man in Diskussionen die Details gar nicht mehr braucht. Früher sind wir mit der Übersichtsliste der Anforderungen und dem Ausdruck der Details zu jeder Anforderung in Abstimmungsmeetings gegangen. Heute haben wir nur noch die Übersichtsliste dabei. Es ist alles viel übersichtlicher geworden.


• Durch die Feature-Beschreibungsform fällt leicht auf, wenn man versehentlich mehere Dinge in einer Anforderung zusammengeworfen hat. Man trennt Anforderungen eher auf und das Risiko sinkt, dass man was Wichtiges übersieht (versteckte Features).


• Durch das Feature-Beschreibungsschema sind unsere Features kleiner geworden. Insbesondere haben wir keine Features mehr, die sehr groß sind. Das ist besonders wichtig, weil wir gerade die großen Anforderungen immer wieder gnadenlos unterschätzt haben.


• Wenn Anwender / Kunden Anforderungen beschreiben, passen die Beschreibungen in der Regel nicht ins FDD-Schema und in den Details finden sich häufig auch mehrere Anforderungen. Wir formen die Anforderungen dann in die FDD-Form um.


• Die Gruppierung in Feature-Sets ist für das Tracking mit Parking-Log-Diagrammen sehr nützlich. In Mantis setzen wir die Kategorien als Feature-Sets ein und verwenden als Richtlinie Feature-Set=Geschäftstätigkeit.


• Major-Feature-Sets bilden wir in Mantis als eigene Projekte an.

Post bewerten

FDD-Reisebericht: Parking-Lot-Diagramme

FDD hat eine bestimmte Art der Fortschrittsvisualisierung: Parking-Lot-Diagramme.

In einem Parking-Lot-Diagramm bekommt jeder Anforderungsbereich (Feature-Set) ein Rechteck, das Auskunft über die Verantwortlichkeit, die Menge der zugehörigen Features, den Fortschritt und den geplanten Fertigstellungstermin enthält.


Abb. nach Leading Answers

Über die aus Scrum stammenden Feature-Burndown-Diagramme hinaus sind Parking-Lot-Diagramme gut geeignet, um den Status großer Projekte zu visualisieren.


Feature-Burndown nach VersionOne

Ein interessanter Aspekt in FDD ist, dass für die Parking-Lot-Diagramme nur die Anzahl der Features gezählt wird ohne Gewichtung. Man geht davon aus, dass die Unterschiede in den einzelnen Featureaufwänden nicht so riesig sind und sich im Mittel ausgleichen.

Ich setze in meinem aktuellen Projekt Parking-Lot-Diagramme zusätzlich zu Feature-Burndowns ein und habe damit gute Resultate erzielt.

Post bewerten

SEE 2007: eine andere Welt

Letzte Woche war ich auf der SEE 2007-Konferenz in München. Die Konferenz sagt das zwar nicht offen im Namen, aber sehr deutlich durch das Programm: Es geht um klassische Vorgehensmodelle a la V-Modell.

Irgendwie war ich selbst als Vortragender zur Geschichte der agilen Methoden auf die Konferenz geraten. Der Vortrag war gut besucht und meine kleine Umfrage am Anfang ergab, dass ca. 95% der Teilnehmer xUnit benutzt, ca. 90% XP kennen und ca. 70% Scrum. Am Ende des Vortrags hatten wir eine angeregte, aber keine kontroverse Diskussion - ich hatte das anders erwartet.

Am Ende gab es dann noch eine Podiumsdiskussion über reichhaltige (cooler Marketinggag das Wording, Respekt) vs. agile Vorgehensweisen. Das Podium war mit 5 Klassikern und Christian Weiss von oose als Agilisten besetzt. Christian Weiss hat darüber im Blog von Bernd Oesterreich berichtet.

Dort schreibt er:

Mir fiel es jedenfalls schwer, Sinn und Zweck von Agilität überzeugend zu verdeutlichen. Vielleicht liegt hier aber auch das eigentliche Problem: Mein Eindruck war, dass beide Fraktionen im Grunde ihres Herzens dieselben Ziele verfolgen.


Letzteres glaube ich nicht so recht, denn: Auf der Podiumsdiskussion gab es eine kurze Phase, in der sich reichhaltig und agil anzunähernd drohten. Das hat der Moderator glücklicherweise unterbunden. Glücklicherweise, weil es nicht darum geht, ob man alle 3 Monate ein Stück Software ausliefert oder ob man auch in agilen Projekten Dokumentation schreibt (wenn es einen Sponsor dafür gibt). Es geht um die Geisteshaltung bei der Softwareentwicklung und um die Perspektive auf Kundenwert, Verschwendung (Lean, Kaizen), Verantwortung, Ehrlichkeit, Menschen und Teams. Und diese Sichtweisen scheinen mir mind. bei den Podiumsteilnehmern (ausgenommen Christian Weiss) gänzlich anders zu sein, als sie in agilen Projekten gelebt werden.

Ich kann mir aber durchaus vorstellen, dass ein Teil der Konferenzzeilnehmer wirklich gerne agil vorgehen würde und nur nicht so recht weiß, wie. Das habe ich jedenfalls aus einigen Diskussionen mitgenommen.

In diesem Sinne arbeiten wir weiterhin daran, Möglichkeiten zu finden, wie man agil vorgehen kann, auch wenn man nach außen nach V-Modell aussehen muss - V-Modell XS.

Post bewerten