Herr User erzeugt sich eine lokale Replik einer Datenbank auf seinem Notebook. Herr User ist leider Chef und damit Gelegenheitsanwender, d.h. er braucht nur einmal im halben Jahr die Datenbank für ein paar Statistiken. Ansonsten wird auch nicht repliziert, da es ja zu viel Zeit kostet.

Frau Anwender ist regelmäßiger User der Anwendung, hat ebenfalls eine lokale Replik und arbeitet täglich damit. Mindestens 1x pro Tag wird repliziert. Im Zuge einer Aufräumaktion wird eines schönen Tages die Datenbank bereinigt, etliche Duplikate werden gelöscht. Die Datenqualität ist bestens, alles ist gut.

Ende des Jahres passiert das Unglück: Herr User braucht dringend die aktuellen Statistiken, schmeißt die Replikation an (“warum dauert das eigentlich immer so lange?”) und zieht eben den Report. Katastrophe, Einträge sind mehrfach vorhanden, völlig unbrauchbare Auswertung. Auch Frau Anwender trifft der Schlag, da auf einmal die ganze Aufräumaktion wieder hinfällig ist.

Was ist passiert? Notes hat eine unschöne Angewohnheit, die dazu führt, dass Löschmarkierungen entsorgt werden. In den Replikationsoptionen einer Anwendung findet sich eine scheinbar harmlose Option:

“Remove documents not modified in the last (days)” ist zwar auf 90 Tage gestellt, aber welcher Wahnsinnige aktiviert schon diese Option? Doof nur, dass Notes dies auch verwendet, um die Ablaufzeit von Löschmarkierungen zu ermitteln, und zwar egal, ob die Option aktiviert oder deaktiviert ist. Nach einem Drittel der eingestellten Zeit werden Löschmarkierungen (deletion stubs) entsorgt. Kann man hier nachlesen. Dies bedeutet für unser Beispiel, dass +/- 30 Tage nach der Aufräumaktion von Frau Anwender die Löschmarkierungen vom Server getilgt werden. Gibt es Repliken, wie die von Herrn User, die in dieser Zeit nicht repliziert haben, dann Pech: die Markierungen sind weg, die Dokumente dafür aber wieder da! Na Gratulation, da hat sich die IBM was feines ausgedacht.

Aber Rettung naht, es gibt nun PIRC (Purge Interval Replication Control). Wenn man einen 8.5.3er Server mit einem 8.5.3er Client paart, dann hat man eine neue Option auf der Replikationsseite:

Was macht diese? Verhindern, dass alter Mist wieder in die Datenbank repliziert wird. Funktioniert es? Ja, aber es muss leider pro Server pro Replik aktiviert werden. Es gibt auch einen langen Artikel, der alle Details erklärt, und einen Blogeintrag bei der Notes-Hexe, aber die Fakten sind einfach:

Repliziert eine nicht-PIRC-Replik mit einer PIRC-Replik, landen nur die Dokumente in der Datenbank, die innerhalb des angezeigten Intervals modifiziert worden sind. Nebenwirkung: Wenn man lange nicht repliziert, werden sehr alte Änderungen der lokalen Replik möglicherweise nicht übertragen. Aber das kann man zum Glück durch einfaches neu abspeichern umgehen.

Kleiner Gag am Rande: In der Doku zu 8.5.3 findet man nichts, weil es diese nicht gibt, sondern immer noch die 8.5.1 Doku ausgeliefert wird. Profiarbeit!

Darf der Kunde also immer nur perfekte Software erhalten?

Für im Echtbetrieb eingesetzte Software gilt die Aussage in jedem Fall. Ein System, welches wie auch immer produktiv genutzt wird, sollte fehlerfrei sein, da sind wir uns einig.

Wenn es sich allerdings um Software handelt, die sich noch im Entwicklungsprozess befindet, kann man diesen Vorsatz oft außen vor lassen. Klar sollten die offensichtlichen Fehler bereits durch den Softwareentwickler und seine Test-Kollegen beseitigt worden sein, aber wenn es um inhaltliche oder Bedienerfragen geht, muss keine Perfektion erreicht sein. Ganz im Gegenteil habe ich bereits sehr gute Erfahrungen damit gemacht, den Kunden so früh wie möglich an “seinem” Produkt teilhaben zu lassen. Wenn man sich als Entwickler nicht monatelang in sein stilles Kämmerlein zurückzieht, sondern den Kontakt mit dem Kunden sucht, ihn oft nach seiner Meinung fragt, dann wird am Ende ein besseres Produkt entstehen. Und wenn ich diese Meinung oft haben will, dann muss ich als Entwickler den Mut haben, auch einmal ein unfertiges Produkt zu präsentieren. Wenn eine Demo nicht ganz perfekt durchläuft, auch mal etwas nicht so funktioniert, wie es sollte, und dafür beim nächsten Termin korrigiert ist, wird der Prozess der Softwareentwicklung deutlich.

Und genau dieser Prozess muss deutlich werden, es muss gezeigt werden, dass Softwareentwicklung ein Handwerk ist, bei dem Mitarbeit gefordert ist. Ohne die Integration des Kunden und seiner Mitarbeiter kann man noch so gut designen, das Endprodukt wird nicht richtig zufriedenstellen. Die beste Software habe ich entwickelt, wenn sich die Endanwender ganz früh beteiligen durften und sahen, wie ihre Tests Auswirkungen auf das fertige Produkt haben. Man nutzt hier aus, dass viele Menschen “etwas bewegen wollen”, auch wenn es nur Kleinigkeiten sind. Die Motivation steigt ungemein, wenn das eigene Wort Gehör findet.

Probieren Sie es als Entwickler: bringen Sie Software früh zum Kunden. Probieren Sie es als Kunde: lassen Sie ihre Anwender früh mit neuen Systemen “spielen”. Die Softwarequalität wird steigen.

Um das Problem zu umgehen, und außerdem noch einmal eine gute Ausrede zu haben, etwas mit der Windows Presentation Foundation (WPF) in C# herumzuprobieren, habe ich den AudioSorter geschrieben. Das kleine Programm erwartet eine Laufwerksangabe und bei einem Klick auf “Sort” werden alle Stücke nach ihrer Tracknummer im ID3-Tag sortiert. Klappt bei meinem Autoradio einwandfrei, vielleicht hilft es auch anderen.

Das Programm kann kostenlos hier heruntergeladen werden: AudioSorter

Aber es gibt eine eigentlich recht simple Lösung. Notes speichert der Erstelldatum in der ReplicaID der Datenbank, wie man bspw. hier nachlesen kann. Also muss die Information nur noch extrahiert werden und das geht ganz gut mit einem API-Call, nämlich ConvertTIMEDATEToText.

Die gesamte Funktion inklusive Deklarationen sieht dann so aus:

Type TIMEDATE
	Innards(0 To 1) As Long
End Type
 
Declare Function ConvertTIMEDATEToText Lib "nnotes.dll" (ByVal IntlFormat As Integer, _
ByVal TimeFormat As Integer, InputTime As TIMEDATE, ByVal retTextBuffer As String, _
ByVal TextBufferLength As Integer, retTextLength As Integer) As Integer
 
%REM
	Function calculateCreationDate
	Description: Berechnet aus der Replika-ID der Datenbank das Erstelldatum
%END REM
Public Function calculateDBCreationDate(strReplicaID As String) As NotesDateTime
	Dim apiTime As TIMEDATE
	Dim session As New NotesSession
	Dim retStr As String * 81
	Dim retLen As Integer
	Dim retCode As Integer
	Dim datResult As NotesDateTime
	Dim strDate As String
 
	apiTime.Innards(0) = Val("&H" & Right(strReplicaID, 8) & "L")
	apiTime.Innards(1) = Val("&H" & Left(strReplicaID, 8) & "L")
 
	retCode = ConvertTIMEDATEToText(0, 0, apiTime, retStr, Len(retStr)-1, retLen)
 
	strDate = Left$(retStr, retLen)
	Set datResult = New NotesDateTime(strDate)
 
	Set calculateDBCreationDate = datResult
End Function

Der erste Tag bot vormittags zuerst ein World Cafe zum Thema “Agile Tookit” und dann zwei Workshop-Runden mit jeweils 4 Tracks. Ich betreibe zwar seit Anbeginn meiner Programmiererfahrung agile Entwicklung (siehe beispielsweise auch den letzten Artikel), habe aber nie einen bestimmtes System verfolgt. Das wollte ich nachholen und habe daher etwas auf Grundlagenworkshops und allgemein brauchbare Themen gesetzt.

“Scrum in 90 Minuten” bot dafür ein ganz gutes Programm, zwei Telekom-Mitarbeiter haben den Workshop vorgestellt, der auch intern durchgeführt wurde. Im großen und ganzen nicht schlecht, fehlte eigentlich nur ein bisschen Inhalt über die Motivation. Von “Scrum Smells” hatte ich mir mehr erhofft, hier wurden 3 Gruppen gebildet, die nahezu ohne Moderatorenhilfe dazu getrieben wurden, die Probleme in Scrum aufzuarbeiten. Die Grundidee war gut, nur gab es im Publikum relativ viele Anfänger und durch die nicht vorhandene Leitung ein bisschen Strukturlosigkeit, so dass das Ergebnis in meinen Augen nicht spannend war.

Es folgte noch eine Open Space Diskussion, das bedeutet, dass die Teilnehmer wieder die Provider von Inhalten wurden. Aus Zeitgründen habe ich nach der Themenvorstellung erst einmal meinen Tag beendet; es gab ja noch einen zweiten.

Der heutige Tag begann mit einer Keynote von Dr. Thomas Kiesling, der die Scrum-Transition bei der Telekom sehr ehrlich und realistisch beschrieb. Echt ein Highlight.

Es folgte mit Ken Schwaber einer der Scrum-Gurus, der für meinen Geschmack allerdings zu viele Gemeinplätze erwähnt, zu viel auf sein neues Buch einging und wenig erhellendes brachte – Ausnahme das geänderte Wording in der aktuellen Scrum-Ausgabe, das einige Nuancen korrigiert. Mit “how to sell Scrum” hatte es nicht so viel zu tun.

Was hatte ich mir an Vorträgen ausgesucht? “(R)evolution durch Agile-Lean Transformation” zeigte ganz gut, mit welcher Argumentation man Agile Entwicklung mit Hilfe von Lean Transformation promoten kann. Als Einstieg in den Tag ok.

“Zusammenarbeit in IT Projekten und andere Wunder” brachte mich etwas weg von der Technik. Warum sind viele IT Projekte so unglaublich schwierig? Weil man sich zu sehr auf die Technik und zu wenig auf die zwischenmenschlichen Probleme konzentriert. Die Erklärungsansätze waren gut, die Ideen ebenfalls. Hat mir gut gefallen, kann man als Consultant gebrauchen.

Ein ganz schwieriger Punkt bei agiler Entwicklung sind die berühmten Festpreisverträge. “Agile contracting” versuchte gegenzusteuern, schaffte es aber leider nur bis Folie 3 mich zu begeistern. Leider endet das Ganze viel zu sehr in einem Modell, das versucht, agil so lange zu verbiegen, bis es klassisch ist. Nicht erhellend.

Hinterher folgte “How to become agile“. Ein Erfahrungsbericht über die Umsetzung von Scrum bei der Telekom, eigentlich die Fortführung der Keynote. Leider etwas hastig vorgetragen, aber grundsätzlich ein interessantes Thema. Spannend, wie ein Behörden-ähnlich strukturiertes Unternehmen wie die Telekom agile Entwicklung versucht.

“Continuous delivery” war mein Starter nach der Mittagspause (Nudeln + Gulasch btw.). Zuallererst fiel die absolut geniale Präsentation auf. Mit Prezi Desktop lieferten die beiden Vortragenden eine super Show und auch der Inhalt passte wirklich gut. Tageshighlight neben der T-Kom Keynote.

Der Abschluss für mich war “Traditionelles Projektmanagement & Scrum“. Wie Feuer und Wasser? Ja, definitiv, der Vortrag brachte auf jeden Fall nicht die Lösung.

Zusammenfassend muss ich sagen, die zwei Tage haben sich schon gelohnt, auch wenn einige Vorträge/Workshops mäßig waren. Alles bat Diskussionsstoff für die Pausen, man kam gut ins Gespräch. Die Erfahrungen der Kollegen waren wirklich erhellend und aus diesen Erfahrungen lernt man.

Was ist die große Erkenntnis? Scrum oder generell agile Entwicklungsmethoden sind sinnvoll und ausgereift; die Probleme ergeben sich derzeit eher in den starren Strukturen des Projektleads und aus dem Sales/Procurement. Solange Festpreisverträge die Regel sind, solange auf Änderungen in den Anforderungen nicht reagiert wird, kann auch die agile Entwicklung nicht ihre Stärken ausspielen. Schade eigentlich.

P.S.: Die Workshops der ersten Tages sind mangels Inhalt auf der Website nicht verlinkt.

Meine Erfahrung ist, dass noch in der initialen Besprechung oft gefragt wird, wann man den nächsten Termin einplanen kann, an dem man sich “einen ersten Entwurf” anschauen kann. Wenn ich jetzt den Termin festmache und dann nur ein abstraktes Datenmodell zeige sowie die Kernalgorithmen präsentiere, kann das kaum jemand einordnen. “Wie weit ist der? 2 Wochen sind rum und es gibt nur ein bisschen Theorie und nicht mal ein Fenster im Programm ist fertig?”.

Wie also kann ich einerseits strukturiert entwickeln (von unten nach oben) und gleichzeitig nicht zu viel Zeit in eine Oberfläche investieren, die sich sicherlich noch mehrmals ändert?

Es gibt viele Prototyping-Applikationen, mit denen man sogenannte mockups erstellen kann, beispielhaft kann man hier Balsamiq oder Axure nennen. Einen ganz anderen Ansatz verfolgt das PowerPoint Prototyping Tookit. Hier wird keine lange Einarbeitungszeit fällig (wenn ich davon ausgehe, dass viele User PowerPoint zumindest leidlich bedienen können) und oft ist die Lizenz für die Software sowieso vorhanden.

Im Prinzip handelt es sich bei dem Paket und eine normale PowerPoint-Datei, die vorgefertigte Bildschirmelemente wie Buttons, Fenster oder Scrollbalken enthält. Diese sind gesammelt vorhanden und können einfach per Copy & Paste zu vollständigen Bildschirmmasken zusammengesetzt werden.

Ich habe das bei einem aktuellen Projekt einmal ausprobiert und war positiv überrascht, wie simpel und zeitsparend sich damit Oberflächen “zusammenkopieren” lassen. Klar, die Genauigkeit von professionellen Tools wird damit nicht erreicht, aber das will ich auch überhaupt nicht. Ganz im Gegenteil, ein bisschen schief ist nicht schlecht, weil der Kunde damit klar erkennt, dass es sich nicht um ein endgültiges Produkt handelt.

Die Kombination von diesem einfachen Tool mit der “wissenschaftlich korrekten” Arbeitsweise stellt beide Seiten zufrieden und am Ende kommt ein Produkt heraus, das passt – und darauf kommt es doch an.

Ich halte mich nicht für den besten Programmierer der Welt und versuche daher, immer Programmcode zu erstellen, den jeder verstehen kann, der einigermaßen sein Handwerk beherrscht. Und damit meine ich, Entwickler, die programmieren können, nicht unbedingt aber in der Programmiersprache, die ich gerade verwende (die Chance ist ja bei LotusScript durchaus hoch).

Jeder Programmierer denkt anders, löst die gleichen Herausforderungen anders, als man es selbst tun würde. Ich selbst löse jetzt Probleme anders, als ich es vor 5 Jahren getan habe. Hierbei meine ich nicht die Verwendung von Sprachfeatures, oder die inzwischen sicherlich bessere Beherrschung des Umfanges einer Sprache – ich meine die verwendeten Algorithmen.

Beim Programmieren von Business Anwendungen geht es zu 80% darum, den Auftraggeber zu verstehen und eine Applikation zu erstellen, die seine Bedürfnisse an Verwendung und Wartbarkeit zufriedenstellt. Und Wartbarkeit schließt ein, dass mein Quellcode von mir, oder auch von meinen Nachfolgern mit dem geringst möglichen Einsatz gelesen und vor allem verstanden werden kann, sollten Modifikationen anstehen. Denn nur wer Quellcode wirklich versteht, kann kosteneffektiv Änderungen vornehmen, die nicht in Hunderten von Folgefehlern münden.

Mein Appell ist also: lesbaren Code schreiben. Dazu gehört anständiges Kommentieren, brauchbare Variablen- und Funktionsnamen und eine gute Dokumentation. Gute Programme lesen sich wie eine Geschichte.

Nicht dazu gehören, jedes mögliche Sprachfeature ohne Rücksicht auf Verluste auszunutzen, kurze oder kryptische Bezeichner zu verwenden, oder innerhalb eines Programms den Programmierstil zu wechseln.

Einen guten Artikel zum Thema, der meine Idee mit guten Beispielen unterstützt, findet sich beispielsweise hier bei IBM.

März 2011 – Programmierung Software x – 1000€

dann folgendes aufgeführt ist:

4.3.2011 Konzeptionierung Programm X, 4h
5.3.2011 Erstellung Mockups für das Benutzerinterface, 2h
5.3.2011 Vorstellung Konzept beim Kunden, 2h
6.3.2011 Programmierung Datenmodell, 8h
9.3.2011 Programmierung Oberfläche, 4h
Summe: 1000€

Dies lässt deutlich weniger Raum für Diskussionen, erklärt außerdem, was man für sein Geld bekommt und die eigene Arbeit erscheint wertiger.

Wie man diese Detaillierung hinbeekommt? Ich für meinen Teil bin nicht so der Freund des Papiers und da ich einen Großteil meiner Arbeit eh am Rechner erledige, lasse ich ein kleines Tool mitlaufen, das mir den Großteil der Arbeit abnimmt. Derzeit verwende ich dafür toggl.com, was für Einzelpersonen kostenlos ist. Supereinfache Stundenerfassung, getrennt nach Kunden und Projekten und eine Vielzahl von Berichten, die man auch gut exportieren kann.

Also, gebt dem Ganzen eine Chance. Auch aus Fairness dem Auftraggeber gegenüber.

Möglich macht das Ganze das Plugin WP-Syntax, das nichts anderes macht, als geshi, einen generischen Syntax-Highlighter in einem Plugin zu kapseln. Das Tolle an der Sache ist die Einfachheit des Einsatzes:

<pre lang=”programmiersprache”>Codeschnipsel</pre>

wobei im Attribut ‘lang’ die Programmiersprache angegeben wird, in der formatiert werden soll. Unterstützt werden gut 100 Programmiersprachen von gängigen wie C, Java oder PHP bis hin zu exotischen wie Brainfuck oder X++.

Und weil es so schön ist, noch ein paar Beispiele:

' Ein bisschen LotusScript
Dim test as new NotesSession

// Etwas C#
public int a = 5;

; ini-Dateien funktionieren ebenfalls
[sektion]
label = value