Vorbemerkung

Open Source

Software ist ein Werkzeug, das ich jeden Tag benutze; deshalb muss ich auch die Kontrolle darüber haben. Ich muss es installieren und modifizieren können, wann und wie es mir gefällt, und ich muss jederzeit dazu in der Lage sein, nachzuprüfen, warum es etwas genau so und nicht anders tut: Nur dann kann ich mir Software als Werkzeug wirklich aneignen.
Von den Kosten gar nicht zu reden: Wenn ich beispielsweise die Funktion einer großen Datenbank kennen lernen will, so ist es von unschätzbarem Wert, dass PostgreSQL Open Source ist. Erst dadurch wird solche Software für Interessierte überhaupt erfahrbar, die nicht in einer einschlägig aktiven Firma arbeiten.
Hier soll nicht vertreten werden, dass Software generell kostenlos zu sein hat; das sieht die GPL (GNU Public License) auch nicht vor. Aber wenn ich Software benutze, will ich Zugriff auf ihren Quellcode haben, unabhängig davon, ob sie Freeware, Shareware oder kommerziell ist.

Dokumentation und Planung

"Nicht notiert heißt: nicht passiert", ist ein Lehrsatz unter Astronomen, und sollte es unter IT-lern auch sein: Denn es wird viel programmiert und noch mehr konfiguriert, aber selten dokumentiert, was gerade getan wurde. Deshalb mache ich bei Arbeitsantritt zuerst den Editor auf und schreibe mit, was ich den Tag über so treibe.

Ebenso die Planung: Mit dem objektorientierten Entwicklungsprozess steht ein ausgezeichnetes Werkzeug zur Verfügung, nur muss man es auch einsetzen. Ohne sorgfältige Planung, ohne möglichst genaue und differenzierte Abschätzung des zu erwartenden Arbeitsaufwandes und ohne Priorisierung der anstehenden Arbeiten bleiben IT-Projekte unkalkulierbar und sind vom Scheitern bedroht.

Webdesign

Content rules! Das Web ist ein Medium, um Informationen zu transportieren. Nach meiner Auffassung bestimmt der Inhalt der Information, wie sie aufbereitet wird: Sie soll den Client schnell erreichen und von ihm möglichst vollständig aufgenommen werden.
Also ist eine Seite entsprechend ihrem Inhalt aufzubauen. Wenn Unterhaltung das Ziel ist, kann sicherlich mit mehr grafischem Aufwand gearbeitet werden, als wenn reine Information im Vordergrund steht. Hier ist das Design weniger offensichtlich; tatsächlich ist es aber vergleichbar aufwändig, eine Seite mit großem Informationsangebot klar zu gliedern und zu navigieren, so dass der Besucher sich darin flüssig bewegen kann und schnell die Informationen findet, derentwegen er auf diese Seite gekommen ist.
Ein gutes Beispiel, wie durch gekonntes Design Information zugänglich gemacht wird, ist für mich http://de.selfhtml.org: SELFHTML von Stefan Münz.

Trennung von Form und Inhalt: So, wie Linux meine erste ernsthafte Berührung mit einem Betriebssystem gewesen ist, war XML mein Einstieg ins Webdesign; das ist die Gnade der späten Geburt. Von dort zurückzugehen auf HTML hieß, seine Unzulänglichkeiten deutlicher zu sehen, als das HTML-native Webdesigner tun, das ist jedenfalls meine Erfahrung.

Erstens ist es sehr viel Aufwand, das Design jeder Seite einzeln zu kontrollieren. Das Aussehen von Strukturelementen lässt sich zwar via CSS zentral festlegen, die Struktur selber aber nicht! Das macht Änderungen im Design einer Website, die aus Dutzenden oder womöglich Hunderten von Einzelseiten besteht, zu einer aufwändigen Angelegenheit.

Zweitens macht das gleichzeitige Erzeugen von Struktur- und Design-Markup die Arbeit am Inhalt der Seite nicht einfacher. Drittens besteht hier auch ein Hinderungsgrund für Arbeitsteilung. Mit XML ist es so sehr viel leichter, Redaktion und Design einer Website zu trennen!

Alle Last dem Server. Noch bis auf Weiteres wird eine Website den Client im .html-Format erreichen. Die Verarbeitung findet auf dem Server des Providers statt; hier haben demnach auch alle Werkzeuge zur Erzeugung dynamischer Seiten ihren Platz. Es mag zwar verführerisch sein, Teile der Serverlast auf die Maschine des Clients auszulagern, z. B. über Javascript; aber erstens ist das eine Art von Übergriff auf die Ressourcen des Clients, die sich mit meiner Auffassung von Service nicht recht veträgt; zweitens ist es in Zeiten, wo immer ausgefeiltere Viren auf den Markt, sprich ins Internet kommen, nicht selbstverständlich, dass Clients ihr Javascript überhaupt aktiviert haben; ich jedenfalls surfe grundsätzlich ohne.
Die Entlastung eines Servers durch clientseitige Vorverarbeitung von Requests usw. spielt außerdem auch eine zunehmend geringere Rolle: Dynamische Inhalte, beispeilsweise von Redaktionssystemen oder über JavaServerPages aus Datenbanken heraus erzeugt, verlangen Ressourcen in ganz anderem Ausmaß.

Sicherheit: Manchmal hat man den Eindruck, das ganze Web fuße auf Treu und Glauben. Angeblich vertrauen über die Hälfte aller XXX-PaySite-Kunden ihre Kreditkarteninformationen ungeschützt und unverschlüsselt dem Netz an! Nun könnte man zwar sagen: selbst Schuld; Tatsache ist jedoch, dass die Benutzung abgesicherter Verbindungen immer noch weder trivial noch komfortabel ist. Leider fehlte auch mir bisher die Zeit, mich mit Themen wie PGP und SSH zu beschäftigen, aber das wird sich ändern, das habe ich mir vorgenommen. Ich mache ja auch die Tür zu, wenn ich das Haus verlasse.
Die meisten schließen sogar ab.

Keep it simple, stupid! Ich bin Minimalist und folge dem Motto: Erreiche ein gegebenes Ziel mit möglichst geringem Aufwand.
Ich bin aber auch Perfektionist; Abstriche an der Funktion zu machen, fällt mir nicht leicht.
Beide Geisteshaltungen ergänzen sich oft prächtig, manchmal aber kollidieren sie. Dann hilft mir aber eine dritte Eigenschaft weiter: Selbstdisziplin gegenüber dem eigenen Schaffensdrang. Wenn eine Aufgabe zu ihrer optimalen Lösung unverhältnismäßig viel Zeit braucht, dann muss es zunächst eine suboptimale tun. Vor allem, wo "optimal" in unserer schnelllebigen Branche nur einen höchst begrenzten zeitlichen Wert hat.

Programmieren

Als Ingenieur verinnerlicht man eine gewisse Denkungsart und bestimmte Vorgehensweisen: planvoll, strukturiert, ausrechenbar.
Das alles trifft auf Software bislang nur bedingt zu. Es sind, soweit ich das sehen kann, zwei Hauptrichtungen in dem Bemühen entstanden, hier Fortschritte zu erzielen:

Die Kathedrale: Vorausplanung eines ganzen Softwareprojektes; Sicherstellung der Wiederverwendbarkeit von Softwareteilen, vielleicht sogar Entwicklung als Framework: Das kommt der Ingenieurseele entgegen. Aber einmal ist da auch noch der Künstler in mir (in welchem Programmierer nicht?), der sich gegen dergestaltige Einschränkungen von Flexibilität und Spontaneität sträubt; und zweitens: Wo findet sich der Kunde, der schon von Vornherein genau weiß, was er will?

Der Bazaar: Die entgegengesetzte Richtung gruppiert sich ums Extreme Programming:
– Stelle zu jeder Zeit eine lauffähige Version deiner Software sicher, wie unvollständig auch immer:
Das mag zunächst selbstverständlich klingen, denn machen das nicht alle Programmierer so, seit die Computer interaktiv geworden sind? Nun, für die einzelnen Programme innerhalb eines Projektes gilt dies sicher. Aber auch für das Ganze? In Zeiten, wo es ein ausgefeiltes Revisionsmanagment braucht, um ein Projekt überhaupt verwalten zu können, ist dies sicherlich nicht selbstverständlich.
– Tue jeden Entwicklungsschritt in Absprache mit deinem Kunden:
Das ist vernünftig. Man muss es nur in der Praxis durchsetzen.
– Programmiere immer zu zweit: Einer schreibt Code, der andere schaut zu, korrigiert und regt an. Wechselt jeden Tag.
Daran wird oft das Revolutionäre von XP festgemacht, und sicher nicht zu Unrecht. Ich sehe aber eine Schwierigkeit: Wo kriegt man den Zweiten her, der in Qualifikation, Spezialwissen und Denkweise gut genug zu einem passt?

Ich sehe die Herausforderung in XP darin, Richtlinien der Selbstorganisation zu finden, die es ermöglichen, große und funktionierende Projekte ohne detaillierte Vorausplanung zu bewältigen. Denn der Vorausplanung sind Grenzen gesetzt: Durch Versionsänderungen der Werkzeuge, die verwendet, und der Software, die eingebunden werden soll; durch den Kunden, dessen Vorstellungen unklar sind oder sich ändern; und durch die Konkurrenz, die ähnliches plant. Diese Liste ist sicher nicht erschöpfend. Sie erhellt aber, dass Flexibilität ein Muss ist, jedenfalls ein Mindestmaß davon.
Die Natur jedenfalls errichet ihre Kathedralen, ohne mehr als ein Gerüst von einem Plan zu haben; aber sie hat sehr effiziente Methoden der Selbstorganisation.
Was der XP-Ansatz in meinen Augen leisten kann, ist eine Öffnung des Denkens in diese Richtung.