Historisch gewachsen ...
Lange habe ich das Bild gesucht, jetzt habe ich es endlich wiedergefunden, es ist von 1991 und gehört zu diesem Editorial in der c't vom 3. Juni 1991.
Meiner Meinung nach ist das Editorial heute noch aktuell, wobei die Inhalte natürlich aktualisiert werden sollten.
Da gibt es Software wie meine Blog-Software Serendipity, die aus - meiner Meinung nach falsch verstandenen - Kompatibilitätsgründen Angst vor dem nächsten grossen Schritt der Weiterentwicklung hat. Und es gibt natürlich sehr viele Projekte, die historisch (hysterisch) gewachsen sind, wobei Altlasten immer mitgeschleppt werden oder versucht wird "einen Glaspalast auf Basis einer Bretterbude zu errichten".
Meistens fällt letzteres nur auf, wenn es Probleme gibt und niemand - oder zu wenige - im Team wissen, wie alle Komponenten zusammenhängen. Basis dieses Defizits ist immer die fehlende oder unvollständige Dokumentation.
Jeder weiss es, jeder braucht sie, aber der Wunsch nach neuen Funktionen ("Features") treibt uns immer weiter nach vorne, ohne zu berücksichtigen, dass dazu auch Text produziert werden sollte, um alle Beteiligten zu informieren. "Mach mal eben" führt langfristig erfahrungsgemäss immer zu Problemen.
Neben dem informativen Charakter hilft Dokumentation auch, einen überblick zu bekommen und je mehr Projektteilnehmer sie lesen, desto grösser ist die Wahrscheinlichkeit, dass Fehler in der Struktur (die oben genannte Bretterbude) auffallen und Alternativen vorgeschlagen werden.
Ich kenne nicht ein Projekt, an dem Administratoren und Entwickler arbeiten, in dem gerne dokumentiert wird. Meistens ist es eine lästige Pflicht. Schade eigentlich. Es gibt den Beruf des "Technical Writers", das sind Leute, die sich darauf verstehen, technische Dokumentation zu schreiben und denen es ausreicht, mit Stichworten gefüttert zu werden. Wo seid Ihr? Viele Projekte warten auf Euch und würden sich freuen, wenn Ihr mitarbeitet.
Je mehr Zeit in neue Features investiert wird, desto mehr Zeit sollte meiner Meinung nach auch in die Erhaltung und Weiterentwicklung der Basis gesteckt werden. Bei einem grossen beruflichen Projekt, an dem ich beteiligt war, wurden alle verfügbaren Mittel ("Ressourcen", schauderhaftes Wort, wenn es um Menschen geht) in die Weiterentwicklung der Funktionen gesteckt und kaum etwas in den Erhalt der Plattform ("Maintenance").
Das führt meistens dazu, dass das komplette Projekt eingestellt und durch ein neues Nachfolgeprojekt ersetzt wird. Welch eine Verschwendung von Geld und Zeit ...
Also, um die Kurve zu "historisch gewachsen" wieder zu bekommen, hier meine Empfehlung: Investiert Zeit und Geld in den Erhalt und den Betrieb der Basis und die Dokumentation. Es macht das Leben um so vieles leichter. Und es hilft zusätzlich auch, neue Teilnehmer in ein Projekt zu integrieren.
Trackbacks
Keine Trackbacks
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Pa_trick17 am :
das ist auch meine Meinung zu dem Thema und es freut mich, wenn diese "grünschnabelige" (was IT betrifft - Lebensjahrmäßig bin ich gar nicht mehr soo jung) Auffassung sich mit der eines eher "älteren Hasen" (ich hoffe Du verzeist mir den Begriff - aber nach der Selbstbezeichnung "alte Säcke" von Roman und Dir in den DeimHart-Podcasts traue ich mich das einfach mal) deckt.
Ein weiterer Vorteil von Dokumentattion -auch auf Open-Source-Projekte angewendet, welche ja oft, vor allem am Anfang, von einem "Zugpferd" mit oder sogar ohne "Flügelmänner" vorangetrieben werden- ist die Herabsetzung des sogenannten LKW-Faktors:
"Wie hoch ist das Risiko, dass das Projekt stirbt, wenn ein Mitarbeiter von einem LKW überfahren wird und sein Wissen mit ins Grab nimmt."
(@Alle, die jetzt denken "Was ist denn mit dem los":
Den Ausdruck gibt es in der Fachwelt wirklich! - Schaut doch mal unter "Truck-Factor")
Gruß
Patrick
Dirk Deimeke am :
Das Schlimme ist aber gerade, dass alle das Problem kennen und keiner etwas daran ändern mag, weil das mit unangenehmer Arbeit verbunden ist, die auch nicht mit "Ruhm und Ehre" verbunden ist.
Pa_trick17 am :
Das Dokumentation nicht meine Lieblingsarbeit ist, auf die ich mich bei meiner gerade startenden "Hobbie-Programmiererkarriere" am meisten freue, und ich in der Anwendung des fertigen Programms diese ja gar nicht bemerkt wird -auch nicht deren Nichtvorhandensein-, also die Arbeit dann nicht mit "Ruhm und Ehre" verbunden ist, geb' ich von meiner Seite aus auch zu.
Es ist allerdings schön, gut dokumentierte Quelltexte zu studieren und eine (gute) Dokumentation der eventuellen Schnittstellen mit anderen Programmen bei eigenen Projekten vorzufinden und hässlich/nervig beim Gegenteil! Das habe ich schon erfahren.
ports am :
Ich dokumentiere alleine schon um meine Ruhe zu haben. Ich moechte nicht im Urlaub angerufen werden, weil es Probleme gibt, deren Loesung in einer guten Dokumentation zu finden gewesen waere.
Dirk Deimeke am :
Für den Busfaktor (oder andere Redundanzen) gibt es noch weitere schöne Analogien.
Wie viele Leute dürfen mittags das Gleiche essen, ohne, dass eine Lebensmittelvergiftung das Projekt lahmlegen kann?
Urlaub, Schulung, Betriebsfeier, ...
Dirk Deimeke am :
Bei mir spielt auch mehr hinein, dass ich einen guten Job machen möchte und dazu gehört, dass die Kisten auch ohne mich laufen ...