Architekturdokumentation

Gernot Starke: Hallo Stefan!

Stefan Tilkov: Gernot wer um Himmels Willen bist du?

Gernot Starke: Hallo Stefan! Vielen Dank, dass ich endlich mal in deinem tollen Podcast sprechen darf. Gernot Starke, bin seit Urzeiten, zum Glück sieht niemand unserer Hörer wie alt ich wirklich aussehe…

Stefan Tilkov: Es gibt Fotos von dir Gernot, Pech gehabt.

Gernot Starke: Das sind alles gefälschte und die sind alle schon ganz alt, das sind keine aktuellen Fotos. Ich bin schon seit – ach im letzten Jahrtausend – in der Informatik unterwegs. Wir sind uns ja auch schon vor gefühlten hundert Jahren das erste mal in Projekten begegnet.

Stefan Tilkov: Was machst du denn so die ganze Zeit?

Gernot Starke: Ganz häufig bin ich bei mittleren bis großen Kunden in Projekten die Software warten, ändern, pflegen und erstellen. Ich hoffe ich Sorge dafür, dass irgend etwas besser wird.

Stefan Tilkov: Was man vielleicht noch erwähnen kann, du bist ein bekannter Autor und es gibt einen ganzen Haufen von Büchern, die man auf deiner Webseite findet und tausende von Artikeln und unzählige Vorträge. Aber du bist viel zu bescheiden das zu erwähnen, deswegen tue ich es für dich.

Gernot Starke: Tu das mal für mich, vielen Dank für die Werbung.

Stefan Tilkov: Wir wollen über Architekturdokumentation sprechen.

Gernot Starke: Ich glaube unsere Hörer wollen das alle gar nicht, dass wir das tun – oder?

Stefan Tilkov: Warum um Himmels Willen?

Gernot Starke: Es gibt ja Gerüchte, die sagen, dass ist das langweiligste Thema unter der Sonne. Das ist natürlich erstunken und erlogen.

Stefan Tilkov: Ist es nicht furchtbar langweilig? Also ich finde das nicht so völlig abwegig.

Gernot Starke: Möglicherweise ist das auch ein bisschen gut so, dass es das ist, weil manchmal meine Kunden mich dafür bezahlen, dass das nicht langweilig ist und dass das alles auch ganz gut geht. Nein, das Thema ist natürlich gar nicht langweilig. Komplexe technische Systeme – wie wir die bauen – zu verstehen ist spannend und nicht langweilig. Und das dann zu Papier zu bringen und in Worte zu fassen, ist auch spannend und gar nicht langweilig.

Stefan Tilkov: Okay. Was kann man denn gegen die Langeweile tun? Wie macht man es denn spannend?

Gernot Starke: Indem man zum Beispiel Dinge die ich verstanden habe – die wir uns mühevoll erarbeitet und diskutiert haben – nicht irgendwo im Kopf bei Seite schiebt und dort liegen lässt, sondern versucht, sie auch mal für Andere nachvollziehbar zu halten und verständlich zu machen. Indem man sie zu Papier bringt, auf Bilder malt, Leuten erklärt und sich vor allen Dingen auch nicht mit dem Erzeugen von Papier zufrieden gibt. Wir wollen nicht möglichst viel Papier bedrucken, sondern Dinge verstehen.

Stefan Tilkov: Vielleicht fangen wir ein bisschen systematisch an, und fragen einfach mal, warum man das eigentlich macht? Was sind denn Gründe eine Architektur zu dokumentieren? Reicht es nicht, wenn ich ein ordentliches System gebaut habe, das ordentlichen Sourcecode hat, der vernünftig geschrieben ist, wohl strukturiert und getestet?

Gernot Starke: Du bist doch sonst nicht so ein Optimist? Du musstest jetzt eine solche Suggestion loswerden. Das reicht natürlich nicht. Das reicht für ganz kleine Systeme bestimmt aus, aber normalerweise reden wir doch über Systeme, die 5–15 Jahre im Einsatz sind. Mein persönlicher Rekord ist ein System, für das es 35 Jahre Gewährleistung gibt. In der Eisenbahntechnologie, da reicht Verständnis von einzelnen Codezeilen oder einzelnen Codesegmenten schlicht nicht mehr aus und es gibt einen Haufen Zeug, das nicht im Code steht.

Stefan Tilkov: Welche Fragen beantworte ich denn mit der Architekturdokumentation? Was nehme ich denn daraus? Was hilft mir das? Was ist der Benefit den ich habe, wenn ich einen großen Haufen Architekturdokumentation habe?

Gernot Starke: Du hast ja selten nur einen großen Haufen. Ich würde dich gerne davor bewahren, dass du einen großen Haufen hast. Das klingt für mich nicht gut, sondern du beantwortest sehr spezifische gezielte Fragen, also du beantwortest sie heute die potentielle Leser oder Software-Entwickler in ein paar Jahren stellen werden. Ja und du möchtest ihnen ja in ein paar Jahren ein Verständnis ermöglichen, wie sie ändern, wie sie erweitern, wie sie bestimmte Aufgaben mit dem System wahrnehmen, wie sie bestimmte Dinge am System verbessern oder verändern können.

Stefan Tilkov: Wann ist so eine Architekturdokumentation gut? Was sind die Anforderungen, die ich damit erfüllen möchte? Was sind die Bestandteile auf die es ankommt?

Gernot Starke: Wenn es uns darum geht, dass wir Systeme langfristig verständlich halten, also dass wir wesentliche Informationen über so ein System, über darin enthaltene Konzepte, über Strukturen zum Ausdruck bringen, dann ist für mich die wichtigste Forderung, das was wir längerfristig festhalten, muss auf jeden Fall richtig sein, also auch keine kleinen Lügen enthalten oder kleine Ungenauigkeiten. Ich darf abstrahieren, aber ich darf nicht lügen. Das ist für mich die erste wichtige Forderung und danach kommt für mich – die vielleicht erstaunlich klingende – Dokumentation muss nämlich wartbar sein. Wir schreien immer nach wartbarer Software und wir haben duzende Muster und Patterns entwickelt, wie wir Software wartbar halten, aber wie wir Dokumentation wartbar kriegen, haben die meisten Leute noch nicht verstanden. Das ist mir ein wichtiges Ansinnen, darum mach ich das zu einer essentiellen Forderung. Und meine dritte, hoffentlich nachvollziehbare Forderung ist, das muss verständlich sein was wir da tun. Also abstruse coole Notationen in seltsamen Sprachen helfen selten weiter. Ja, wir müssen das Verständlich gestalten so, dass auch in ein paar Jahren noch irgend jemand das Zeug aufschlägt oder die Wikiseite öffnet und sagt: „Wow, das verstehe ich.”

Stefan Tilkov: Was ist mit Vollständigkeit? Ist es wichtig, dass ich alles dokumentiert habe? Wie detailliert muss denn Architekturdokumentation sein?

Gernot Starke: Das ist total überbewertet. Ich bekomme die Krise, wenn mir jemand sagt: „Ich will vollständige Dokumentation haben.” Das ist dieser 70er und 80er Jahre Ansatz – „Ich kann die gesamten Daten eines Unternehmens alle genau modellieren” - welch ein Blödsinn. Niemals kann ich das machen. Ich will keine vollständige Dokumentation, sondern relevante, aktuelle und verständliche haben. Das ist mir viel wichtiger als vollständig.

Stefan Tilkov: Wie entscheidest du denn, was relevant ist? Das ist doch eine wahnsinnig willkürliche Entscheidung, oder? Der eine dokumentiert das, der andere dokumentiert das. Ist es so, Hauptsache ich habe irgendwas, denn irgendwas ist besser als nichts? Oder wie kommst du zu der Entscheidung, was tatsächlich wichtig ist?

Gernot Starke: Da stellst du eine ganz gute Frage. Ich entscheide das gar nicht, was relevant oder was notwendig ist, sondern ich gehe im Team hausieren und frage Leute: „Was haltet ihr für relevant und wichtig?” Das ist eine Feedbackschleife, die wir das drehen. Wir nähern uns von unten sparsam, wir dokumentieren ein bisschen. Dann gehen wir zu den typsichen Stakeholdern, den Leuten die mit unserer Dokumentation leben und arbeiten müssen, zeigen denen Stücke und sagen:„Reicht das? Sind das die richtigen Dinge? Sind da die für euch wichtigen Aspekte beschrieben?”. Damit nähern wir uns dann einer Angemessenheit oder einer Relevanz.

Stefan Tilkov: Lass uns mal einen Schritt zurück gehen. Du musst mich mal überzeugen. Ich stelle mich mal auf die Position: „Das ist alles irgendwie Unsinn!”. Ich will nicht das da irgendwer rumrennt und eine abstrakte Dokumentation schreibt, die nachher keiner liest. Wie näher ich mich dem denn? Wie kriege ich das hin? Wer erstellt das und wann wird das erstellt? Ist das dabei danach oder davor? Und wer macht das? Ist das der Dokumentator? Oder ist das der Architekt? Oder sind das alle Entwickler? Wie bettest du das denn in so einen Prozess ein?

Gernot Starke: Ich fang mal mit der ketzerischen Aussage an – „Wenn du die Idee hast danach zu machen, dann kannst du das auch direkt bleiben lassen!”. Danach kann sich eh kein Mensch mehr erinnern und danach haben wir nie Zeit, weil wir danach schon das Nächste zutun haben. Es gibt kein danach. Es gibt nur ein dabei. Ich kann nichts vorher dokumentieren, weil vorher weiß ich es noch nicht. Ich kann es nur dabei machen.

Stefan Tilkov: Das heißt, du würdest praktisch eine Verlaufsdokumentation machen? Dokumentierst du alles was mal zwischendurch gegolten hat und hast dann eine chronologische Historie oder gibt es zu jedem Zeitpunkt immer das was gerade den aktuellen Stand widerspiegelt und der Rest ist mir egal?

Gernot Starke: Wenn ich Korrektheit ernst nehme, muss ich Dokumentation auch aktualisieren. Wenn sich wesentliche Dinge ändern, muss ich das irgendwie nachpflegen und das sollte sich in Dokumentation widerspiegeln, dass sich eben etwas wichtiges geändert hat, sonst habe ich Fehler. Und so wie wir Fehler in Code nicht haben wollen – wir eliminieren und refaktorisieren, so muss ich das auch in Dokumentation machen. Deswegen will ich sparsam und wenig dokumentieren, damit ich schnell in der Lage bin Änderungen dort nach zu pflegen und wieder zu finden.

Stefan Tilkov: Klingt so als wäre es die gleiche Forderung die man am liebsten auch an Software stellen würde. Nicht unnötig aufgebläht, sondern so simpel und so einfach wie möglich, um das Ziel zu unterstützen. Das gleiche soll auch für die Dokumentation gelten.

Gernot Starke: Das Ziel läuft doch in Software, also Code doch ganz wunderbar, also wenig und leicht änderbar. So will ich Dokumentation sehen. So möchte ich Dokumentation in Projekten und großen Systemen verankern. Wenig, schlank, einfach und vor allem so, dass wir während wir an dem System arbeiten, auch an der Dokumentation arbeiten. Und wenn wir Entscheidungen treffen, wenn wir uns gegen ein Framework entscheiden, mit wichtigen Argumenten, dann ist das eine Entscheidung, die ich niemals im Code finde. Das reicht mir dann nicht nur die Code zu betrachten, sondern da muss ich irgendwo Gründe für so eine Entscheidung festhalten. Die ergeben sich im Projekt, die muss ich dann aufschreiben, wenn ich sie treffe.

Stefan Tilkov: Lass uns vielleicht mal auf die Mittel eingehen. Was ist denn Dokumentation, also wie drückt die sich aus? Ist das Papier ist das ein Word-Dokument, wie ist das strukturiert? Welche Mittel benutzt du um Architekturdokumentation durchzuführen?

Gernot Starke: Jetzt hatten die werten Hörer gerade nicht die Chance mich schaudern zu sehen, als du Papier gesagt hast. Am liebsten hätte ich gerne Dokumentation als eine vernünftige Kombination aus Text und Bild. Ich mag Bilder, ich bin visuell, ich mag Skizzen, meinetwegen dürfen Bilder auch ein bisschen formaler sein. Das ist aber gar nicht relevant, weil Bilder schaffen eine schöne Übersicht, Bilder zeigen Strukturen, Bilder zeigen Zusammenhänge. Ich muss aber immer Bilder über Text erläutern. Die die mich kennen, die wissen das, ich bin ein ganz penetranter Tabellenschreiber. Ich finde das ich ein Bild und eine Tabelle zusammen, also die Dinge die in dem Bild erkenne, systematisch erläutere oder auch nur einige davon erläutere. Das finde ich ist eine ideale Kombination. Das ist das Erste, das ich als wesentliches Mittel für eine Dokumentation sehe, Text und Bilder. Für mich gehören Beispiele zur Dokumentation. Also wenn wir über technische Dinge reden – Konzepte, Frameworks, wie setzen wir Dinge um, dann würde ich mir immer eine kurze Erläuterung, am liebsten einen Unit-Test, ein Acceptance-Test, der mir Code beschreibt, „Wie ist es gemeint?”. Das finde ich als sehr sehr nützliches Hilfsmittel für Dokumentation.

Stefan Tilkov: Das heißt ein Test wäre für dich Teil einer Architekturdokumentation?

Gernot Starke: Das kann man ganz ganz sinnvoll dafür verwenden. Das muss man nicht tun. Nicht für alle Stellen einer Architekturdokumentation haben Tests eine Relevanz, aber wenn ich technische Konzepte erläutere, also so übergreifende querschnittliche Themen sind Code-Schnipsel Prima und dafür kann ich auch Tests verwenden, um etwas zu beschreiben.

Stefan Tilkov: Eine typische oder häufige Frage ist, oder ein häufiges Problem ist, das man vor einem weißem Blatt Papier oder vor einem weißem Bildschirm sitzt und jetzt irgendwie starten soll. Es gibt von dir ein Hilfsmittel, von dir und Peter Hruschka das wir auch häufig einsetzen, das ist arc42. Kannst du dazu ein bisschen was sagen? Was ist das und was bringt mir das so etwas zu benutzen?

Gernot Starke: Ich antworte da mal mit einer Gegenfrage. Du hast doch bestimmt zu Hause, eine Art Schrank im Badezimmer stehen, wo ihr die Artikel, die ihr für das tägliche Leben im Badezimmer als Familie braucht irgendwie geordnet habt?

Stefan Tilkov: Von geordnet würde ich jetzt nicht sprechen, aber der Rest war korrekt, ja.

Gernot Starke: Vielleicht hätte ich nicht über eure Familie sprechen sollen, aber Spass bei Seite. Ihr habt eine Art irgendwie geordneten Schrank und wenn du mal zum Einkaufen gehen darfst, und bringst halt Zahnpasta, Shampoo und Ohrenstäbchen, was weiss ich mit, dann hilft dir dieser Schrank, dieser halbwegs geordnete Schrank weiter, dass du diese Dinge die du da geschaffen hast oder beschafft hast, das du die wiederauffindbar an eine vernünftige Stelle platzieren kannst. Ich sehe arc42, eine Architekturdokumenationsmethode als einen Schrank an. Du kannst die Türen auf machen, du hast eine feste Ordnung, wo gewisse relevante Dinge für Systeme halt für dich vorstrukturiert sind. Da gibt es eben passende Fächer für. Wenn du heute Lust hast an einer Schnittstellenbeschreibung zu arbeiten oder einem Schnittstellenkontrakt, oder du schreibst Code für irgendeine Datenbankoptimierung und willst da erläutern was du getan hast, dann hat das alles einen festen Platz in diesem Schrank. Hast du keine Lust mehr, keine Zeit mehr machst du die Schranktür zu und dann ist gut. Dann kann der am nächsten Morgen der Nächste kommen den Schrank öffnen und wieder weiterarbeiten.

Stefan Tilkov: Also das was mir arc42 gibt, ist im Prinzip eine vorgefertigte Struktur an die ich mich halten kann.

Gernot Starke: Eine vorgefertigte Ordnung für Dinge, die für Architekturdokumentation vielleicht relevant sein können. Wohlgemerkt können nicht müssen. Also der Schrank wird wahrscheinlich für dein konkretes System ein bisschen zu groß sein, ein bisschen zu viele Fächer enthalten, dann schmeisst du halt welche raus.

Stefan Tilkov: Sag doch mal ein paar Beispiele. Was dokumentiere ich da drin? Was ist in der Struktur so drin?

Gernot Starke: Was ich am liebsten für jedes System wissen möchte, ist der Aufbau im ganz großen. Wir nennen das in arc42 Level 1 Whitebox Sicht. Also die wesentlichen Dinge, die großen Bestandteile, Komponenten, Module, Subsysteme meines Systems und deren Verbindungen, plus Beziehungen zur Außenwelt. Also statische Betrachtungen, höchster Abstraktionslevel der mir hilft Teams vernünftig einzuteilen, Strukturen im Großen zu erkennen, Technologien zu platzieren. Das lauter solche wichtigen Fragen beantwortet. Es gibt mir einen tollen Überblick.

Stefan Tilkov: Ich finde das interessant, das nehme ich immer als Standard Scherz wenn ich Architekturvoträge halte, die meisten Leute, wenn man sie fragt, wie ihre Architektur aussieht, malen so ein Schichtenmodell und haben dann irgendwie Datenbank, Logik und UI und das finde ich immer sehr tragisch, denn das was du gerade gesagt hast, ist ja eher eine fachliche Struktur. Welche Systeme, welche Teile habe ich? Und nicht welche Schichten habe ich in meinem System.

Gernot Starke: Möglicherweise habe ich da auch eine Kombination aus beidem. Diese drei Schichten oder vier oder fünf, wie auch immer sind mir normalerweise zu unspezifisch.

Stefan Tilkov: Das passt halt immer.

Gernot Starke: Ja, das passt möglicherweise sogar zu Erdbeerkuchen. Ich denke eine Ebene spezifischer können wir noch werden und wir haben da auch immer fachliche Bestandteile drin. Wir haben aber auch schon oft sehr sehr technische Dinge, die da auf einer hohen Ebene auftauchen.

Stefan Tilkov: Eine Sache die darin auftaucht sind Sichten. Kannst du ein bisschen erklären warum man Sichten verwendet in Dokumentation?

Gernot Starke: Hast du schonmal versucht deinem Lieblingselektriker Zuhause nur den Grundrissplan zu geben, ohne ihn so ein bisschen spezifisch darüber zu informieren, wo denn bei euch die Kabel gelegt sind? Euer Haus ist ja auch schon ein paar Jährchen älter. Wo nicht alles was zur Technik des Hauses gehört, aus dem Grundrissplan erkennbar ist. So sehe ich auch Software für Sichten geeignet an. Ich möchte gern verschiedene Perspektiven haben. Ich möchte gern wissen, wo sind die statischen Teile. Das möchte ich getrennt davon betrachten – Verteilung, Deployment, Infrastruktur – als eine Sicht oder Perspektive. Wir haben in arc42 ein paar sehr einfache Standardsichten vorgeschlagen. Ich hab Kunden, die brauchen andere oder noch ein paar mehr. Das kann man durchaus auch machen. Ich sehe es als sparsam an. Man fängt mal mit wenigen Sichten an. Eine Baustellensicht haben wir in jedem Fall, wenn wir über Code reden und eine Verteilungssicht haben wir praktisch immer, wenn wir über Systeme reden, die auf mehr als einer Hardware ablaufen oder möglicherweise verteilt Teile unseres Systems laufen.

Stefan Tilkov: Wenn ich mir das so anhöre und Architekturdokumentation als Begriff höre, dann kann ich mir vorstellen, löst das bei manchen Leuten so eine leichte Allergie aus. Also irgendwie klingt das so unagil. Das klingt alles so „Big Design up front”. Du hast ja jetzt schon gesagt man macht das so nebenbei und erstellt das, aber irgendwie fühlt sich das so an, glaube ich zumindest für viele Leute, das das so nicht ist, was man da macht. Wie passt denn so ein Dokumentationsanspruch zu so einem modernen agilen Projekt?

Gernot Starke: Ich habe in den letzten Jahren bestimmt zehn, zwölf agile, dynamische Projekte begleitet und viele Scrum Teams oder Teams, oder Teams, die so ähnlich arbeiten wie Scrum, also in hochgradig iterativen, Feedback intensiven Modellen und ganz viele von denen haben so etwas gemacht, was sich neudeutsch „Definition of Done” nennt. Und in jeder „Definition of Done” stand drin, wir wollen dokumentieren. Viele haben es nicht gemacht, das stand immer auf der Rückseite, das waren dann die Teile, die die Leute ignoriert haben, aber wenn wir eine überraschende Entscheidung für ein Framework für ein Konzept für die Implementierung eines Systemteils in Clojure treffen, dann möchte ich gerne, dass das Team das auch akzeptiert und diese Entscheidung sollten wir begründen. Das war vielleicht überraschend und nächstes Jahr versteht vielleicht niemand mehr warum wir das so gemacht haben. Das Verständnis für den Code, das können wir durch Tests gegen diesen Code ganz gut transportieren, aber das Verständnis für solche Entscheidungen müssen wir dokumentieren und das passt auch gut zu Agil. Auch agile Teams wollen 6 Sprints später noch ein bisschen verstehen, was sie da getan haben und warum sie es getan haben.

Stefan Tilkov: Ja, das kann ich sehr gut nachvollziehen. Eine Sache die ich vielleicht noch ergänzen würde, ich finde es hilft auch dabei, wenn man diese Entscheidung dokumentiert, das man nicht unbedingt den einen zentralen Architekten braucht. Was ja auch so ein agiler Ansatz ist, das ich eben Architektur-Ownership auf mehere Leute verteile, das alle an der Architektur beteiligt sind, macht es viel leichten, wenn sich vielleicht mal drei Leute mal zusammensetzen diskutieren und diese Entscheidung dokumentieren, dann bekommen die Anderen das mit und können vielleicht sagen: „Nene, das machen wir anders.”, aber ich muss es nicht unbedingt zentralisieren, wenn ich die Dokumentation praktisch als Hilfe benutze um eben nicht alles in einem Kopf oder in einem Team zu haben.

Gernot Starke: Das ist mir auch ein ganz wichtiges Anliegen. Mein Verständnis von Architektur ist eher das es eine Rolle ist, die ein Team ausfüllen muss. Wo es in der Regel jemanden gibt, der einen verantwortlichen Teil da übernimmt, der im Zweifel in der Lage ist eine Entscheidungsneurose in dem Team aufzulösen, ob mit der Faust auf den Tisch oder durch Überzeugung oder durch geschicktes taktieren, das sei mal da hingestellt. Das ist bestimmt ein Thema für einen weiteren Podcast. Das ist für mich schon eine wichtige Aufgabe, die man durchaus in dem Team vergeben sollte. Jemand, der hilft, jemand der im Zweifel dann die Verantwortung für so eine Entscheidung übernehmen kann. Aber die Dokumentation selber erstellen, das muss nicht der Eine machen. Vielleicht ist da im Team einer, der ein bisschen dokumentationsresistenter ist. Ich kann mir das bei dir nicht so wirklich gut vorstellen. Spass, das schneiden wir vielleicht raus. Aber wenn ein Teil des Teams eine Entscheidung trifft, dann sollte dieser Teil des Teams dafür zuständig sein, die dafür relevanten und langfristigen Informationen dafür festzuhalten, im Wiki, im Modell, auf dem Whiteboard und sie abfotografieren, wie auch immer.

Stefan Tilkov: Das ist vielleicht noch einmal ein interessanter Punkt. Du hast gerade Fotografie gesagt, du hast Bild, Text und Tabellen erwähnt. Gibt es vielleicht noch andere Artefakte andere Arten von Medien, die man benutzen kann, um Architektur zu dokumentieren?

Gernot Starke: Naja, wenn wir etwas ordentlich machen ist vielleicht ein Wiki und ein Modellierungswerkzeug und ein guter Codeeditor, wo ich ein bisschen Code in mein Wiki kriege, schon so eine gute dreier Kombination von Werkzeugen. Viele Teams arbeiten ja gerne an Whiteboards, Flipcharts, mit Papier und oft besteht wenig Wert darin, dieses Papier dann abzumalen, das will ich nicht tun. Manchmal macht das Sinn, aber oftmals macht das keinen Sinn, dann ist sowas, wie eine digitale Kopie eines solchen Papiers aufzuheben bestimmt eine schlaue Idee. Das ist kompakt, das geht schnell. Wenn an so einem Bild dann viele Leute weiterarbeiten sollen, dann macht es bestimmt Sinn sich zu überlegen ein mehrbenutzerfähiges ordentliches Werkzeug zu nutzen.

Stefan Tilkov: Was hältst du von Videos?

Gernot Starke: Darf ich das kurz beantworten. Nichts, solange ich in Videos keine Volltextsuche habe. Ich hab mit einem Team Videos aufgenommen. Wir haben die Architekten interviewt über wirklich mehrere Stunden und dann stand ich eines Tages vor dem Problem, ich musste ein bestimmtes Teil des Systems modifizieren, wo es um eine relativ komplexe kryptographische Operation ging, die ein Architekt erläutert hat und ich hab echt in diesen Stunden Videos diese Stelle nicht gefunden. Teamkollegen um mich rum haben sich lustig gemacht und gesagt, jetzt musst du dir dieses ganze Zeug noch stundenlang anhören. In Videos ist das mit fast forward ein Problem. Das war der Moment, wo ich eingesehen habe, Videos sind kein passendes Instrument. Für Geeks ist das mal sehr cool etwas mit HD Kamera aufzunehmen, aber ich rate davon ab.

Stefan Tilkov: Ich könnte mir theoretisch vorstellen, aber ich gebe auch zu ich habe das noch nicht gemacht, ich könnte mir theoretisch vorstellen, wenn man es von Anfang an sauber indiziert und einzelne Fragen stellt – aber ich stimme auch zu das ist schon deutlich schwerer zu durchsuchen, als andere Dinge.

Gernot Starke: So ein schönes kompaktes Bild, vielleicht wo wir ein Werkzeug haben, das jeder benutzen kann, meinetwegen ein Plugin für ein nettes Wiki oder auch ein Modellierungswerkzeug, wo jeder dran ändern kann, wo ich eine Änderungshistorie habe, dass find ich viel viel effektiver als dann im Video zwar die Stelle zu finden, aber ich kann diesen Teil vom Video ja nicht mehr ändern. Dann arbeite ich mit Schnittwerkzeugen an meinem Video, nein, nein, das wollen wir in Softwareprojekten nicht machen.

Stefan Tilkov: Du hast Modellierungswerkzeuge erwähnt. Was ist denn deiner Meinung eher ein Modellierungswerkzeug oder eher ein gutes Malprogramm? Ist es Enterprise Architect oder ist es MS Visio oder OmniGraffle?

Gernot Starke: Ich würde mir eher ein Modellierungswerkzeug wünschen, weil mir das so viele Änderungen erleichtert. In einem OmniGraffle, in einem verteilten Kontext irgend so ein Ding umzubenennen – was es an drei anderen Stellen auch noch gibt – da vergesse ich welche. Das fällt mir bei einem Modellierungswerkzeug leichter. Dafür ist die Einstiegshürde bei einem Modellierungswerkzeug für das Team höher, das muss man abwägen. Wenn wir als Team länger als ein Jahr zusammen arbeiten, dann krieg ich jedem soviel Enterprise Architect oder Visual Paradigma oder irgendwas beigebracht, so ein minimal Set, das ich kennen muss. Es muss niemand einen schwarzen Gürtel in UML machen, um ordentlich dokumentieren zu können.

Stefan Tilkov: Aber du würdest es auch nicht ablehnen und sagen ach UML, das ist ja zwanzigstes Jahrhundert das machen wir doch heute nicht mehr?

Gernot Starke: Ganz im Gegenteil, ich find das ist eine etablierte Notation. Ich setze das sehr pragmatisch ein. Ob man die Pfeile links oder rechts herum zeichnet, das ist mir meisten ziemlich egal, wenn wir nicht Code daraus generieren wollen, das will ich fast nie. Ich finde das schon als etwas positives, das ich eine Notation habe, wo es auch eine Menge gedruckte Bedienungsanleitungen zu gibt. Da gibt es eine Menge wissen zu. Viele Hochschulabsolventen kennen das minimal Set, das man braucht. Viele Unternehmen haben solche Werkzeuge im Einsatz. Das passt schon, da kann man das schon gut verwenden. Das Risiko, dass man das missbraucht ist halt sehr hoch. Das man anfängt formalistisch zu werden und sich dann mehr mit seinem UML beschäftigt, als mit seinem System beschäftigt. Das Risiko gibt es, das habe ich bei Kunden erlebt, mit drastisch schlechten Effekten, will ich nicht wiederholen. Aber man kann das auch sehr sparsam sehr pragmatisch einsetzen. Stefan Zörner hat mit seinem DokChess, die URL können wir in die Podcast Notes schreiben, ein wirklich sehr spannendes und sehr – finde ich – pragmatisches Beispiel auch gezeigt, wie man UML in ganz kleinen Schnipseln einsetzen kann, um ein cooles IT-System zu verstehen. Ich mache keine Werbung für unseren eigenen Beispiele, sondern verweise da lieber auf Stefan, das kann man sehr angemessen, sehr schlank auch nutzen.

Stefan Tilkov: Gut, hast du ein paar schöne abschließende Worte für uns? Was sollten wir mitnehmen, wenn wir uns auf ein paar Dinge konzentrieren wollen? Die wichtigsten Dinge, die man mitnehmen sollte, wenn man den ganzen Rest vom Podcast vergisst? Was wäre das?

Gernot Starke: Seid systematisch sparsam, versucht so wenig wie möglich zu machen, aber Null ist keine Option, nichts machen geht nicht. Das geht ein paar Monate gut, irgendwann holt es einen ein und Dokumentation tut immer dann weh, wenn ich sie nicht habe. Dann hätte ich doch lieber etwas gemacht. Um das zu vermeiden, find ich den Spruch cool, den mir der Peter Hruschka und die Kollegen von der Systemsguild mal beigebracht haben, „One throat to choke.” – „Ein Hals zum würgen.”. Gib die Verantwortung für Dokumentation an eine Person. Du bist dafür zuständig, das wir ordentliche Dokumentation bekommen. Du musst das nicht alles machen, du darfst das gern delegieren, aber lass das eine Person machen. Nennt den dann meinetwegen den Wikigärtner. Das finde ich, ist eine schöne Bezeichnung. Ein Gärtner soll sähen und pflanzen, der soll aber auch ausrupfen der soll aber auch brutal löschen, wenn es passt und wenn ich diese eine verantwortliche Person hab, dann wird alles gut.

Stefan Tilkov: Alles klar, vielen Dank Gernot bis zum nächsten mal.

Gernot Starke: Vielen Dank Stefan, für die interessanten Fragen und bis bald.

Stefan Tilkov: Tschüss Zuhörer!