Software Engineering Blog

Durch Artikel im Projektmanagement-Blog und im Blog von Jens Coldewey bin ich über Youtube (nein hier gibt es keinen Link) auf Prof. Peter Kruse aufmerksam geworden.

In diesem Video erklärt Prof. Kruse sehr gut, warum Veränderungsprozesse auch immer durch die oberste Ebene einer Organisation mitgetragen werden müssen und eine Änderung von unten nie erfolgreich ist. Und falls doch, dann nur, weil die Führung durch eine Reihe von Krisen so geschwächt ist, daß sie dem Änderungsdruck von unten nichts entgegen setzen können.

Für uns und unsere Projekte bedeutet dies, daß Veränderungen nur erfolgreich sind, wenn wir die Unterstützung der wichtigsten Stakeholder haben oder einfach der richtige Zeitpunkt dafür gekommen ist.

Vor einiger Zeit habe ich ein Phänomen beschrieben, welches ich Event-Driven-Software-Development nenne und dessen Kern von Martin Fowler als Technische Schulden beschrieben wird.

In Fowlers Blog habe ich jetzt einen Verweis auf ein Video von Ward Cunnigham gefunden, in welchem er den Begriff Technische Schulden erläutert und in 4 Minuten und 44 Sekunden auf den Punkt bringt.

Was Gutes gibt es selten für 'n Appel und 'n Ei. Aber manchmal doch. Atlassian bietet jetzt bis zum Freitag, den 24. April, sein Issue-Tracking-System JIRA und das Wiki Confluence in der Enterpriseversion beschränkt auf fünf Benutzer für sage-und-schreibe fünf Dollar an. Die Lizenz kann für jeweils fünf Dollar maximal drei Jahre verlängert werden.

Gerade für kleine Firmen oder Gruppen ist das ein unschlagbares Einstiegsangebot. Natürlich spekuliert Atlassian darauf, so durch die größere Nutzerbasis auch füher oder später mehr große Lizenzen zu verkaufen. Doch gerade für den Einstieg mit JIRA und Confluence ist das ein unschlagbares Angebot.

Übrigens, das Geld wandert nicht in die Taschen von Atlassian, sondern alle Einnahmen aus dieser Aktion gehen an das Projekt Room to Read.

Wie der Heise-Newsticker meldet, wechselt das Gnome-Projekt das Versionskontrollsystem und löst damit Subversion durch GIT ab.

Das an sich ist mir noch keinen Eintrag wert, aber darüber bin ich auch einen Vortrag von Linus Thorvalds zu GIT aufmerksam geworden, der sehr interessant (und auch unterhaltsam) ist. Thorvalds spricht darin über eine Ansichten zur Versionskontrollsystemen und den Vorteil von verteilten Systemen gegenüber einem zentralisierten Ansatz wie er früher von CVS und jetzt auch von Subversion verfolgt wird. Insgesamt auf jeden Fall empfehlenswert, darum hier das Video zum Vortrag:

Mit vielen seiner Ansichten legt Thorvalds den Finger auf wunde Punkte in Versionskontrollsystemen und zeigt Alternativen auf. Auch seine Ansichten dazu, was ein Branch ist, sind richtig. Nach ihm entsteht defacto schon ein Branch dadurch das man die Working Copy verändert und damit eine neue Codelinie defacto eröffnet. Denkt man das konsequent zu Ende, ist eine in einer IDE geänderte Datei auch schon ein neuer Branch.

Nach meiner Meinung weist Thorvalds aber auch auf einen richtigen Punkt hin: Verteile Entwicklung in Open Source-Projekten erfordert sicherlich einen anderen Umgang mit Versionkontrollsystemen als ein räumlich zentralisiertes Projektteam. Bei zentralisiert arbeitenden Teams, die auf eine schnelle Integration von Änderungen auf einen zentralen Branch angewiesen sind, scheint mir Subversion und Co. im Vorteil zu sein.

Aber es ist wohl wie immer: Die Wahl des richtigen Tools hängt immer von der konkreten Situation ab.

Gernot Starke hat in seinem Blog einen Hinweis auf seinen auf der WJAX
gehaltenen Vortrag zum Thema Architekturkommunikation hingewiesen, der als Video online zur Verfügung steht.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

• Architektur beschäftigt sich mit Strukturen und Konzepten.
• Implizite Annahmen treten immer da auf, wo etwas nicht
  dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
• Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
  das einfach mal heterogene Projektentwicklung. Klingt doch
  netter.)
• Architektur ist nicht das Kodieren von selbigen, da Code
  allein ab einer gewissen Größe keine Basis für Verständnis
  ist.
• Verständnis (von Architekturen) muß erst geschaffen werden und
  kann erst danach gefördert werden.
• Dokumentation muß minimalistisch sein, womit gemeint ist, daß
  nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
  die für das Verständnis der Anwendung notwendig sind.
• Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!

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.

Im Sophisten-Blog hat Alexander Lindner einen Tipp veröffentlicht, wie Aktionen in Entscheidungstabellen leicht zu referenzieren sind. Die Idee ist ziemlich gut. Hier geht es zum Blog-Eintrag.

Gute Software kann mit einem Haus verglichen werden. Für Häuser gilt, daß zwei Dinge in Ordnung sein müssen: das Dach und der Keller. Das Dach schützt gegen Wasser von oben und der Keller gegen Wasser von unten. Wenn diese beiden Dinge in einem guten Zustand sind, befindet sich auch das Haus in einem guten Zustand.

Der Keller einer Software sind die eingesetzten Technologien. Und um diesen Keller fachgerecht zu bauen, muß man sich mit den Grundlagen der Technologieren auseinander setzen. Daher lese ich seit Jahren immer wieder die Artikelserie Effective Java von Angelika Langer und Klaus Kreft, die seit 2002 im JavaSpektrum erschien und seit Mitte diesen Jahres im JavaMagazin fortgesetzt wird.

Mir ist keine andere vergleichbare Serie bekannt, die sich über einen so langen Zeitraum auf einem konstant hohen Niveau mit Grundlagen von Java beschäftigt und die notwendigen Zusammenhänge veranschaulicht. Oft werden die relevanten Grundlagen leider von aktuellen Hypes übertönt, aber es kann wichtiger sein, die richtige Implementierung von equals(Object o) und hashCode() zu kennen, als die neueste Version des Frameworks XYZ.

Angelika Langer hat dankenswerter Weise ältere Artikel der Serie auf ihrer Homepage veröffentlicht, sodaß die gesamte Serie auch noch nach Jahren abrufbar ist. An dieser Stelle auch Dank an die Verlage, die dem zugestimmt haben.

Seit kurzem gibt es eine eigenen BSD-Kanal auf Youtube mit Vorträgen rund um BSD auf verschiedenen Konferenzen.

Auch wenn Videos mehr Zeit in Anspruch nehmen als Texte - die kann man leichter mal zur Seite legen oder ein, zwei Seiten überspringen, sind sie doch ideal, als entspannende Informationsquelle. Vorallem dann, wenn Sie so wie Jason Dixons Vortrag "BSD is Dying" daherkommen.

(weiterlesen...)

In den letzten Tagen habe ich mich auf die Suche nach verfügbaren Modellierungswerkzeugen für Geschäftsprozesse gemacht, die BPMN als Notationsmöglichkeit unterstützen. Die großen Anbieter für UML-Modellierungswerkzeuge unterstützen meistens auch BPMN als Notationsform, selten aber in einer Personal Licence oder in der Community-Edition.
(weiterlesen...)