Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.
– Dick Brandon

(das der Kerl auch noch so heißen muss macht das Zitat noch griffiger) :-) In den nächsten Wochen Tagen darf ich ausschließlich dokumentieren. Merkt man das?

Heute abend bin ich beinahe an einem ganz bescheuerten Bug verzweifelt der so dämlich ist, daß ich es mir nicht nehmen lasse ihn hier zum besten zu geben:

Vorlauf: Kunde meldet sich, "nix geht mehr". Ok, schauen wir mal. Tja, Tools laufen, MySQl Tables auch ok, nur.. irgendwie kann man nix mehr inserten!
Wir hax0rn mal sicherheitshalber:

Hä was ist denn des? Ich pfusche noch eine Weile herum bis klar ist, daß man nur noch was eintragen kann wenn man der auto_increment Spalte definierte Werte gibt. Aber das Schöne an auto_increment ist halt das Auto, ja, teilweise wie im richtigen Leben auch. Der geht nimmer! Warum? Weil auto_increment nicht wieder bei 1 anfängt, wenn er voll ist. Dann gibts ein truncate. Angeblich geht das aus der Doku hervor aber ich bin heute dafür nicht gemacht.

Und ja, das bedeutet daß seine DB bis zum heutigen Tage an die 2,2 Mrd. Positionsmeldungen verarbeitet hat. Manchmal schon praktisch, daß man sowas nicht von Hand machen muß :-)

Nach inzwischen einigen Jahren in der Bearbeitung von Fehlern bei CRM Software beginnen sich ein paar klare Linien abzuzeichnen. Man kann es sicher verallgemeinern, aber das laß ich erstmal. Wenn man für ein etwas größeres Projekt verantwortlich ist, bekommt man natürlich auch alle Fehler mit die der Kunde meldet oder die intern entdeckt werden. Durch unser Anfragesystem werden sie in Gruppen klassifiziert, entsprechend den Softwaremodulen bzw. den logischen Einheiten. Beispiel: Materialverwaltung, Kundenstamm, usw.
In diesen zynischen Zeiten der Gewinnmaximierung steht natürlich immer die Begrenzung der Kosten obenan, das ist bei uns nicht anders. Nachdem das nun eine Zeitlang fröhlich ausgewertet wurde kam heraus, was alle schon längst wußten: Die Dauerbaustellen machen die meisten Probleme. Nichts ungewöhnliches soweit. Jetzt werde ich natürlich oft nach der Ursache dieser Probleme gefragt (das ist der unangenehme Teil mit der Verantwortung). Die Antwort ist entweder kurz das Symptom (Schludrigkeit, Verschlimmbesserung, Funktionalität nicht kapiert, Seiteneffekt übersehen, Inkompetenz (ja, gibt es auch), mehrdeutige Konzeption, Verteilungs- oder Runtimefehler, falsche Versionierung, Altlasten) oder ich versuche mich in einem Vortrag über den Grund, weshalb diese Probleme an besagter Stelle gehäuft auftreten. Im Duell zwischen Konzeption und Entwicklung gibt es natürlich kaum eine Chance, diese Probleme der Konzeption zuzuschieben, so attraktiv es auch erscheinen mag. Aber trotzdem gibt es eine Beziehung zwischen gewissen Konzepten und einem Berg von Programmfehlern. Durch geeignete Konzeptionierung lassen sich diese Engpässe nämlich bedeutend verringern. So könnte man es machen:

• Abläufe und Verfahren sollten möglichst gleich sein. Das erwartet der Benutzer und erleichtert der Entwicklung die Verwendung von gemeinsamen Code.
• Der Anwendungsfall sollte so simpel wie möglich sein. Ernsthaft. So simpel wie es geht. Aber wenn es nun mal komplex ist? Dann in primitive Einzelteile zerhacken. Denn die Entwickler sind Simpel, und die Kunden erst recht ;-)
• Nie, gar nie, einfach nie im Leben sollte eine neue Funktionalität quasi als "Trittbrettfahrer" auf eine vorhandene Funktion "aufgepfropft" werden. Das geschieht etwa so: "Huch, der Kunde will gern eine neue Funktion XYZ, aber hier haben wir ein Modul, das macht schon XY, also machen wir doch eine kleine Erweiterung dafür und basteln eine Markierung rein, mit der man unterscheiden kann, ob das Modul jetzt XY wie gewohnt oder XYZ macht". Das ist zunächst sicher plausibel, denn die Kosten bleiben im Rahmen. Doch später geht die Entwicklung weiter und bald wird klar, daß hier zwei ein Bett teilen, die nicht zusammen gehören. Nur ist leider in der Zwischenzeit alles viel zu kompliziert geworden, als daß man sie noch mit vertretbaren Aufwand trennen könnte.
  Ich meine das nicht aus Entwicklungssicht (da ist die Lage anders: gemeinsamer Code in die Basisklasse, usw.) sondern aus konzeptioneller: "Die Extrabonuspunkte sind ja so ähnlich wie die Sonderbonuspunkte.. naja, also, dann könnten wir sie ja zusammen in einer Maske anzeigen nur im Falle von XYZ muß dann in der Spalte ZZZ anders gerechnet werden....". Man ahnt ja, worauf das hinausläuft.

Auf seiten der Entwicklung wird nur zu gern der Fehler gemacht, den Code unter entwicklungsmäßigen Gesichtspunkten in verschiedene Module zu unterteilen. Beispiel: "Diese drei Funktionen verwenden alle die Library XY, von daher müssen sie in ein Modul zusammengefaßt werden". Natürlich gibt es immer wiederkehrende Elemente, die man gut zusammenfassen kann: Datenbankkonnektivität, Kommunikationsmodule, Standardmasken. Aber nur zu oft passiert es, daß zum Beispiel zur Auflösung des Referenzpfads irgendein Modul hinzugefügt wird, nur weil dort eine Methode ist, die man gerne verwenden würde. Die Lösung hieße eigentlich Refakturierung und wird leider nicht von allen Kollegen verstanden und ausgeführt. Das Ergebnis ist dann, daß auf einmal Abhängigkeiten zwischen Dingen bestehen, die aus Anwendersicht nichts miteinander zu tun haben. Der Kunde versteht dann (zu Recht) nicht, warum z.B. für die Funktion des Wareneingangs das Kundendienstmodul benötigt wird.
Hier gilt einfach, die Abhängigkeiten so gering wie möglich zu halten. Das hat den Vorteil, daß man es leichter hat, wenn z.B. nur einzelne Programmteile portiert werden sollen. Ich hab gut reden! Darf ich doch jeden Tag mit einer Codebasis arbeiten, an der o.g. Probleme zuhauf vorhanden sind. Ein Grund brauche ich halt um das mal loszuwerden ;-)

Ich muß hier mal kurz nen Tip loswerden: JAlbum hat mir gestern eine Menge Arbeit erspart. Großartiges Tool, daß das Erstellen einer Galerie für Urlaubsbilder o.ä. ganz einfach macht. Nicht viel Klickerei und zwei entscheidende Merkmale, die mir persönlich ganz wichtig sind:

1. Relative Pfade und nur Javascript. Die Galerie funktioniert demnach genauso lokal, auf einer Backup-CD und im Web
2. Skalierung und Bearbeitung nicht im Web. Diesen Weg gehen viele Plugins für Blogs. Falls die Arbeit im Web geschieht, müssen erst die unskalierten Bilder hochgeladen werden was bei den meisten Upstream-Raten nicht besonders dolle ist. Gestern habe ich die fertige Galerie mit 300+ Bilder in einer knappen halben Stunden hochgeladen.

Was mir nicht so gut gefällt ist die relativ unintuitive Art, die Bilderverzeichnisse hierarchisch anzuordnen, der "Top"-Link meines Wurzelverzeichnisses zeigte regelmäßig ins Leere. Das kann man aber durch eine index.html im übergeordneten Verzeichnis wieder einfangen.