Jetzt steht der Termin endgültig fest und die Einladung ist via XING auch raus.
Also am 10. März 2009 um 18:30 Uhr werde ich vor der JUG Berlin-Brandenburg in einem Vortrag TestNG als Alternative zu JUnit vorstellen.
Die Folien oder besser gesagt das PDF zum Vortrag werde ich nach dem Vortrag hier veröffentlichen.
Nach "Der Termin" erschien von Tom DeMarco 2001 "Spielräume", in dem sich DeMarco mit der Notwendigkeit auseinandersetzt auch unter hoher Belastung genügend Freiräume zu schaffen um auch langfristige Ziele verfolgen zu können. "Adrenalien Junkies und Formular-Zombies" ist die aktuelle Veröffentlichung von Tom DeMarco mit seinen der Atlantic Systems Guild-Partnern. In diesem Buch setzen sich Tom DeMarco und seine Partner mit aus ihrer Sicht typischen Verhaltensmustern im Projektgeschäft auseinander. Hierfür stellten sie 86 in Projekten beobachtete Verhaltensweisen zusammen, bei denen es sich sowohl um empfehlenswerte Muster als auch um Anti-Muster handelt. Die Muster beschreiben Verhaltensweisen, die zum Erfolg der beobachteten Projekte oder zum Gesamterfolg der sie praktizierenden Firmen beigetragen haben. Entsprechend beschreiben die Anti-Muster projektgefährdende Verhaltensweisen. Wer "Der Termin" kennt, wird viele Muster als auch Anti-Muster wiedererkennen können. Das Muster "Der Bleistiftstummel" ist beispielsweise die Entsprechung dazu, daß sie Webster Tompkins um eine gute Ausstattung seiner Projektteams kümmert, um deren Produktivität sicherzustellen. Auch die Rolle von Aristoteles Kenoros, dem Leiter des moravischen Software Engineering Institutes, findet sich indirekt in "Alte Hüpfer und junge Hasen" wieder. Dieser sich häufig einstellende Wiedererkennungseffekt und die leichte Schreibweise machen "Adrenalien-Junkies und Formular-Zombies" zu einer angenehmen und leichten Lektüre, wodurch die Schwächen den Buches kaschiert werden. Den das Buch leidet zum einen unter einer mangelnden Struktur. So sind die Muster weder nach einem ersichtlichen Schema strukturiert, noch als Muster oder Anti-Muster gekennzeichnet. Zum anderen divergieren die Musterbeschreibungen sowohl in Hinsicht auf Qualität und Umfang. Teilweise werden Muster umfangreich auf vier Seiten beschrieben, andere Muster bringen es auf nicht mehr als eine Seite. Das dem Leser keine Hilfestellungen für sein Handeln in bestimmten Situationen an die Hand gegeben werden und die mangelnde Untermauerung mit Fakten sind aber die Hauptmängel des Buches. Hier bieten andere neuere Erscheinungen wie "Softkills für Software-Entwickler" mehr Rüstzeug für den Projektalltag, auch wenn sie sich nicht so leicht lesen wie "Adrenalien Junkies und Formular Zombies". Auch bot hier Projekttagebuch von Webster Tompkins, welches am Ende jedes Kapitels geführt wurde, mehr und bessere Ansätze.
Wie auch schon bei "Der Termin" besteht der Charme des Buches darin, daß viele Verhaltensweisen mit eigenem Erlebten übereinstimmen. Der Wert von "Adrenalien Junkies und Formular Zombies" liegt darin, einen auf diese Punkte aufmerksamzumachen und einem die Möglichkeit zu verschaffen, eigene oder beobachtete Verhaltensweisen zu reflektieren, die aufgrund des Shifting-Baseline-Effekts selbst nicht mehr wahrgenommen werden. Trotz dieser überwiegend positiven Aspekte weist das Buch also schwere Mängel auf und zählt nicht zu den publizistischen Höhepunkten im Schaffen von Tom DeMarco, ist aber auf jeden Fall, auch wenn nur zur Reflektion, eine Anschaffung wert, denn alle von ihm beobachteten Punkte sind wahr.
Als Fazit bleibt festzuhalten, daß der Wert von DeMarcos Büchern in seiner Fähigkeit liegt, die in Projekten und Firmen herrschende Realität zu beobachten und uns auf bisher publizistisch-hohem und unterhaltsammen Niveau mitzuteilen. Seine Popularität begründet sich darin, dies wahrheitsgemäß zu tun und das seine Beobachtungen mit den Wahrnehmungen seiner Leser übereinstimmen. Gleichzeitig sollte uns die Notwendigkeit solcher Menschen wie Tom DeMarco auch Anlaß sein darüber nachzudenken, wie und von wem Projekte geleitet werden.
Liebe ich Java? Ja, das tue ich. Sicher, Java muß aufpassen nicht den Anschluß an die Entwicklung "moderner" Sprachkonzepte zu verpassen, aber etwas moderater Konservatismus kann nicht schaden. An vorderster Front zu stehen kann auch gefährlich sein und tödlich. Außerdem geziemt es sich nicht für eine "Business-Language" sich in jedes Getümmel zu stürzen.
Es gibt aber auch Dinge in Java oder der API, die haben mich in den letzten acht Jahren immer wieder wahnsinnig werden lassen. Beispielsweise der Umgang mit Zeitangaben. Allein, daß sich Calendar im Package java.util befindet, drückt doch schon eine gewisse Geringschätzung aus...
Wer Businessanwendungen schreibt hat es täglich mit Zeitangaben in seinen Anwendungen zu tun wie: jeden Tag um acht Uhr, sieben Stunden lang oder vom ersten bis zum zehnten jeden Monats. Für all das bietet das JDK nur Date und Calendar als Ausdrucksmittel. Beide Klassen beziehen sich vereinfacht gesagt immer auf einen konkreten Zeitpunkt unter Angabe von Tag und Uhrzeit. Beides stellt also einen festen Punkt auf einer Zeitachse dar.
Damit lassen sich aber die oben genannten Beispiele nicht ausdrücken. "Vom ersten bis zum zehnten" bezieht sich auf zwei Punkte auf der Zeitachse. Sollen Fragen wie "Liegt folgendes Datum im Zeitraum oder davor oder sogar danach?" zwingt uns die API immer mit zwei Datumsangaben zu hantieren. Sollen zwei Datumsangaben mit Calendar noch schnell mit Tages oder Monatsgenauigkeit überprüft werden, läßt sich das auch nicht in einer Zeile bewerkstelligen, da Calendar-Instanzen immer auch Zeitangaben enthalten.
Eine neue API für den Umgang mit Zeit ist also mehr als überfällig und Rettung naht auch schon in Form des JSR 310 Date and Time API der unter der Leitung von Stephen Colebourne und Michael Santos entwickelt wird.
Colebourne ist übrigens auch verantwortlich für das JodaTima-Projekt, welches heute schon eine alternative API für Zeitberechungen bereitstellt und von http://joda-time.sourceforge.net/ heruntergeladen werden kann.
Die Grundkonzepte von JodeTime sind die folgenden Datentypen:
xs:durationUm diese Datentypen bauen Colebourne und Santos nun auch die API für den JSR 310 auf die eventuell schon in der 7er Version von Java unter javax.time enthalten sein wird. Dazu kommen die notwendigen Klassen zur Verarbeitung von Datumsangaben. Insgesamt hinterläßt die API einen sehr mächtigen Eindruck. Zur Zeit ist sie leider noch sehr instabil, wer aber die Mailingliste zum JSR 310 verfolgt, merkt das aktiv an der Spezifikation und Implementierung gearbeitet wird. Einen guten Überblick über die verfolgten Ziele liefert auch die Präsentation von Colebourne auf der 2008er JavaOne.
Wer bis zu Version 7 nicht warten will, kann jetzt schon bei JodaTime Hilfe finden.
Vor langer Zeit habe ich einmal eine Vorlesung zum Thema Softwareengineering bei Prof. Schlingloff an der Humboldt-Universität besucht und wir bekamen die Aufgaben gestellt die folgenden Begriff zu ordnen:
Das war damals Anstoß für mich, mich tiefer mit Fehlerursachen in Softwaresystemen zu beschäftigen. Dabei wurden wir auch auf das Standardwerk zur Systemzuverlässlichkeit hingewiesen: J.C. Laprie, A. Avizienis, H. Kopetz: Dependability: Basic Concepts and Terminology. Springer-Verlag (englisch, deutsch, französisch). Bedauerlicherweise zählt dieses Buch zu den etwas teueren Fachbüchern. Bei Amazon in Deutschland wird es für gut 200€ angeboten. Bei Amazon in Amerika kann es schon für gut 100$ erworben werden.
Dank dem großen Google konnte ich ein Paper von Laprie, Avizienis und Randell finden, in dem die wichtigsten Konzepte zur Systemverlässlichkeit zusammengefaßt sind.
Für Menschen die sich auch gerne konzeptionell mit solchen Dingen auseinandersetzen ein Kleinod. Haben Sie schon einmal mit einem Kollegen stundenlang über die richtige Exception-Handling-Strategie gestritten? Dann schicken Sie ihm doch einfach den Link zu diesem Artikel... 
Hier kann das Dokument gefunden werden...
Es gibt manchmal Leute, die schätzen einen so hoch, daß man bei vielen Punkten sofort als Ratgeber in Anspruch genommen wird. Zu einen fühlt man sich ja immer geehrt so hoch geschätzt zu werden, aber bei manchen Fragen stellt sich dann doch die Frage: "Hättest Du das nicht ersteinmal googlen können?"
Scheinbar geht nicht nur mir das manchmal so, sondern auch die Machern von letmegooglethatforyou.com...
Einfach eine nette Art jemanden dies auch auf eine indirekte Art zu sagen.
Hier noch zwei Querverweise zu meinem letzten Artikel Event Driven Software Development, die ich gefunden habe.
Feature-Suppe nennt Tom DeMarco das von mir beschriebene Phänomen, wenn einer Software unkontrolliert und nur auf kurzfristigen Nutzen hin ausgerichtet neuen Funktionalitäten hinzugefügt werden. Als Grund hierfür sieht er das Fehlen einer Person, die das große Ganze im Auge hat und unter diesem Aspekt die Entwicklung koordiniert. Nachzulesen ist dieses Anti-Pattern in
Adrenalin-Junkies und Formular-Zombies - Typisches Verhalten in Projekten
.
Technical Debt lautet die Bezeichnung hierfür bei Martin Fowler die Bezeichnung. Im Unterschied zu Tom DeMarco liegt sein Fokus aber auf den technischen Problemen die sich aus kurzsichtigen Umsetzungsstrategien ergeben. Schnell hinzugehackte Funktionalitäten ala „Chef, in drei Stunden ist das fertig! Dafür muß ich nur hier noch kurz …“ freuen zwar manchen und sind sogar manchmal möglich, doch in der Regel werden bei so sogenannte technische Schulden angehäuft, die irgendwann samt Zinsen wieder abgezahlt werden müssen und zwar dann, wenn all die Schnellschüsse in eine saubere und wartbare Architektur oder Konzept überführt werden müssen.
Alles braucht einen Namen und was wir nicht benennen können ist schwer bis gar nicht in unserer Begriffswelt unterzubringen und es fiele auch ziemlich schwer über diese Dinge zu sprechen, die wir nicht benennen können. All das, dem wir einen Namen geben können existiert und wir können es zum Gegenstand unserer Betrachtungen machen.
Ein gutes Beispiel hierfür ist Event Driven Software Development. Als Abkürzung ist EDSD etwas sperrig, ausgesprochen klingt es nach Dynamik und Aktivität, und strotzt nur so vor Energie. Vom Namen her hat Event Driven Software Development her also die absolute Chance zum neuen Shotting-Star der Software-Entwicklung aufzusteigen.
Wir alle wissen, daß sich die Anforderungen an unsere Software schon recht früh ändern können und die Änderungswünsche nicht nur von außen, sondern auch innen, direkt aus dem Team kommen. Im Idealfall erkennen wir Dinge, die anders, besser und effizienter erledigt werden können oder es wird schnell mal eine Funktion eingebaut, die die Sonderkonstellation 4711 wunderbar abdeckt. Dann kommen noch anderen Abteilungen auf uns zu, die für die eine Veranstaltung oder jeden Kunden eine bestimmte Funktion brauchen. Wir als Softwareentwickler verstehen uns natürlich als Dienstleister nach innen und außen und bemühen uns allen gerecht zu werden und jeden Wunsch so gut wie möglich umzusetzen. All dies bezeichne ich als Events auf die wir bei der Entwicklung reagieren müssen und die sich als Change Request auf die Entwicklungsziele auswirken können.
Unsere Aufgabe ist es diese Events zu steuern und ihre potentielen Auswirkungen einzuschätzen und sie zu managen. Je weiter ein Projekt voranschreitet, desto geringer sollten die Änderungen an ihm werden, da wir sonst unser Ziel nicht erreichen können oder es zumindest gefährden. Also ist die Zeit ein wichtiges Kriterium bei der Behandlung von externen Ereignissen, die zu Änderungsanforderungen führen können. Bis hierher wird es sicherlich keinen Widerspruch geben.
Aber kann jede Änderung, die nicht hinsichtlich Zeit unkritisch ist, auch umgesetzt werden? Nein lautet hier die Antwort. Jede Änderung muß auch danach beurteilt werden, wie gut sie sich in das Produkt, also die Software, einfügt und auch zu den Zielen, die erreicht werden sollen, beiträgt.
Letztendlich zeichnen sich gute Produkte auch durch Konsistenz aus. Konsistenz stellt daher auch ein Qualitätsmerkmal dar, daß es im Auge zu behalten gilt. Denn die wirklich guten Produkte sind in sich konsistent.
Bei jeder Änderung muß also auch kritisch gefragt werden:
Diese Fragen müssen jedesmal gestellt und beantwortet werden. Falls diese Fragen zu keinem positiven Ergebniss führen, sollte die Änderung hintenangestellt werden, denn ansonsten sind wir nur am Hin-Und-Her-Springen und verlieren Zeit und Qualität. Diese Punkte, scheint mir, werden zu oft vergessen, denn kurzzeitiges Denken siegt oft über langfristigen Erfolg. Denn die Rechnung kommt erst später, denn je später eine notwendige Korrektur erfolgt, desto teurer ist sie.
Event Driven Software Entwicklung ist also ein Anti-Muster und verweist auf eine schwache Steuerung innerhalb eines Projekts und sollte die Frage nach der Projekt oder Firmenkultur aufwerfen.
Meine These lautet: Gute Software ist eine notwendige Voraussetzung für langfristigen Erfolg.
Richtig ist aber auch, daß gute Software ein notwendiger Grund für Erfolg ist, aber kein hinreichender. Nur aufgrund guter Software stellt sich kein Erfolg ein, aber es wird leichter erfolgreich zu sein.
Um mit anderen Leute Erfahrungen auszutauschen, ist es auch heute in der (hoffentlich) bald post-2.0-Ära auch am besten, wenn man sich direkt trifft und frei über alle Themen reden kann, die einen interessieren. Doch oft fehlt es an den notwendigen Orten dafür. Ideal sind Orte an denen man sich nicht nur einmal oder sporadisch trifft, sondern die sich auch fest etabliert habe und somit ein fester Bezugspunkt sind. Solche Orte können als Katalysatoren dienen. Denke man hier nur einmal an die Künstlersalons früherer Zeiten.
Solch ein Ort in Berlin kann der newthinking store in Berlin in Berlin werden, über den ich über die JUG Berlin aufmerksam geworden bin.
Ich zitiere die Homepage:
Der newthinking store ist ein Raum für Präsentationen und Veranstaltungen. Über 800 Veranstaltungen, 30 Webmontage und hunderte Präsentationen aus dem Startup-Bereich fanden hier in den vergangenen vier Jahren statt und bilden eine erfolgreiche Plattform für verschiedenste Player aus dem Web2.0 Umfeld. Programmierer, Designer, Webentwickler, Netz-Aktivisten, politisch Interessierte oder einfach interessierte Laien kommen zu unseren zumeist kostenlosen Events und tauschen sich aus. Wir holen das Prinzip der Freien Software an einen realen Ort:
Ein fester Treff- und Informationspunkt der die Stärken, Vorteile und politischen Gestaltungsspielräume von Freier Software einer breiten Öffentlichkeit nahebringt und so einen Raum für eine lebendige Community bietet. Ihre Community?
Für alle also, die in Berlin einen Raum für Veranstaltungen suchen, der wirklich zentral liegt und das nicht nur verkehrstechnisch, sondern auch im übertragenen Sinne, der sollte sich den newthinking store ansehen. Die Preise sind auch sehr moderat, wie man dem Factsheet entnehmen kann.
Softwerker - und inzwischen wohl auch die meisten anderen Büroarbeiter - verbringen eine riesige Menge von Zeit mit dem Bearbeiten von Mails. Die meiste Zeit dabei wohl mit dem Lesen derselben. Daher ist auch hier wie bei vielen anderen Dingen das richtige Rüstzeug.
Ich persönlich benutze Thunderbird. Auch wenn er teilweise kleine Schwächen hat, ist es doch das beste Mailprogramm mit dem ich zurecht komme. Sein wohl größter Vorteil ist eine Erweiterbarkeit durch Addons, also Plug-Ins. Im Laufe der Jahre habe ich mich permanent für sieben Addons dauerhaft entschieden, wobei ich wohl dutzende ausprobiert habe. Interessanter Weise nutze ich für Firefox kaum Plugins. Wahrscheinlich reicht es mir Webseiten zu lesen und mein Bedürfnis meinen Browser zu tunen ist bei mir so hoch wie ein Auto zu tunen. Wo ist der Mehrwert?
Meine Thunderbird-Addons bieten mir jedoch einen Mehrwert von dem ich so überzeugt bin, daß ich die wichtigsten in der nächsten Zeit vorstellen möchte. Hier ist die Liste der Addons:
Alle Artikel werden das Tag "Thunderbird Addon" haben, worüber sie leicht zu finden sein sollten.
Certified ScrumMaster
Im Moment durchsuchst du die Software Engineering Blog Blogarchive für Februar 2009.