Ideen für den Buchhandel

Wie könnte sich denn nun der Buchhandel auf eine neue Art von Leserschaft einstellen?

Mit meinem vorherigen Blogartikel habe ich erstmal nur ein wenig aufrütteln wollen. Mir liegt etwas am Buchhandel oder besser: an Buchgalerien, in denen ich in pBooks stöbern kann und von deren Auswahl und Präsentation an Büchern ich mich inspieren lassen möchte. Deshalb wollte ich dem Buchhandel einmal berichten, mit welcher Art von Lesern er es (auch) zu tun hat. Nämlich mit solchen, die ihn benutzen, ohne ihm etwas dafür zu geben. Klingt hart, ist aber so.

Vorgestern habe ich das wieder getan, diesmal in Münster. Die Thalia-Buchhandlung dort hat mir zwei schöne Lesetipps vermittelt. Die habe ich mir in meiner iPhone Amazon App gemerkt und bin wieder gegangen. Auf meine Frage ans Personal, wie sie es denn mit eBooks hielten, hatte man keine überraschende Antwort: “Die finden Sie im Internet.” Ach, ach was.

Also: Wie könnte es der Buchhandel denn besser machen? Das bin ich seit meiner Nachricht an den Buchhandel öfter gefragt worden. Denn besser als diese Thalia-Antwort geht es bestimmt.

Natürlich kenne ich kein Patentrezept. Die Silberkugel habe auch ich nicht gegossen. Allerdings bin ich mir in einem sicher: Wenn es besser werden soll, dann muss es anders werden. Ziemlich anders. Und das auch noch ziemlich schnell. Immerhin droht 40% der Buchhandelsfläche in den nächsten 5 Jahren das Aus, prophezeit Carl Halff, Chef des Weltbild-Medienversands. Und das, obwohl seine Einschätzung des iPads sehr, hm, konservativ ist:

“Für Bücher ist das iPad ungeeignet, zu unhandlich und zu schwer, um damit länger zu lesen, auch nicht blendfrei.”

Aus seiner Sicht liegt die Zukunft des Buchhandels im Multichannel geschäft, d.h. Buch allein bringt es nicht. Aber Buch + Notizbuch zum Buch + Tasse zum Notizbuch zum Buch + Schrank zur Tasse zum Notizbuch zum Buch usw., das bringts. Wirklich? Hm… Für mich verschwimmt da eher der Unterschied zum Kaufhaus immer mehr. Wenn ich heute im Supermarkt oder auch in der Videothek Bücher kaufen kann, wodurch zeichnet sich dann der Buchhandel der Zukunft aus, in dem ich Videos oder Nahrungsmittel kaufen kann?

Irgendwie mögen solche Läden dann Geld verdienen. Gratulation. Aber mit Buchhandel hat das dann für mich nicht mehr viel zu tun. Schon heute ist das Personal im Buchhandel meist recht unverständig. Man kann Bücher räumen und am PC bestellen. Aber beraten… das können die meisten nicht. Überblick – auch nur über eine Sparte –, den haben die meisten nicht. (Besser ist das nur in Antiquariaten. Dort sitzen Enthusiasten.)

Multichannel ist aus meiner Sicht also nicht die Lösung, sondern eine Unterwerfung. Wer als Buchhandel ein Problem hat und dann die Bücher, d.h. die Träger von Inhalten zurückfährt und auf Bauchladen umsattelt, der wechselt schlicht die Branche. Lidl hat kein Problem mit dem Buchverkauf, Karstadt auch nicht. Aber die haben dafür andere Probleme. Ob man also gut beraten ist, die Probleme des Buchhandels gegen andere auszutauschen?

Aus meiner Sicht schlägt Herr Halff also keine Lösung vor, sondern ein Ausweichmanöver für Unternehmen, denen letztlich egal ist, was sie verkaufen. Aus Vorstandsicht natürlich plausibel. Derzeit z.B. im Vorstand von Thalia: Albert Hirsch, der auch schon in Software und Mineralwasser gemacht hat, oder Oliver Reul, der aus dem Bereich Logisik zu kommen scheint und auch schon bei T-Mobile gearbeitet hat, oder Michael Weber, der Erfahrung bei Star Finanz, HanseNet und Tchibo gesammelt hat. Was soll ich als Buchfreund da denken? Dass diese Herren sich dem Buch, den Buchinhalten verpflichtet fühlen, dass sie ein genuines Interesse am Lesen und an Lesern haben? Nein, leider kommen solche Gedanken bei mir nicht auf.

Da lobe ich mir echte Buchhändler wie Andrea Nunne mit ihrem kleinen Laden oder die Geschwister Heymann mit ihrer kleinen Ladenkette in Hamburg. Denen geht es um die Inhalte. Und nur von denen erwarte ich in Zukunft auch echte Hilfe bei Selektion und Präsentation, weil es zukünftig vor allem darum geht: Inhalte. Bücher lagern, bestellen, verschicken ist keine Kompetenz mehr, die ein Buchhändler braucht. Alles, was mit der Form von Büchern zu tun hat, ist eigentlich nicht mehr sein Thema. [1]

Was kann der Buchhändler aber nun besser machen in Bezug auf sein Thema? Wie kann er die Umwandlung in einen Bauchladen vermeiden? Hier ein paar Ideen aus meiner Sicht als Leser:

Idee #1: Embrace

Wenn es weh tut, dann mach mehr davon. Diesen Rat an alle, die etwas verbessern/lernen wollen, kann ich nur dem Buchhandel geben. Wenn online Buchverkäufe weh tun, dann versucht mehr damit zu machen. Wenn eBooks weh tun, dann versucht, mehr davon zu verkaufen. Oder wenn nicht verkaufen, dann zumindest besser verstehen, mehr selbst nutzen.

Wenn´s im Bauch zwickt, muss man nicht sofort zum Arzt laufen. Mal einen Tag aushalten und schauen, ob es weggeht, reicht meist aus. Die Schmerzen durch online Buchhandel und eBooks sind aber nicht vorrübergehend. Soviel ist schon heute klar. Wer also noch aushält und darauf wartet, dass es von allein besser wird, der hofft vergeblich.

Wenn aber klar ist, dass Schmerzen Symptome einer ernstzunehmenden Krankheit sind – 40% Flächenverlust für Bücher scheinen mir ziemlich ernst –, dann ist Aktivität angezeigt. Dann muss schleunigst nach einer Kur gesucht werden. Dann darf man sich dem Problem nicht verschließen.

Im Falle des Buchhandels bedeutet das für mich: ausprobieren, mitmachen, selber machen, mehr machen, besser machen. Unvermeidliche Veränderung sollte begrüßt werden. Jeden Morgen ein Hoch auf die neuen Medien singen, ist das Mindeste. Jedem Angestellten ein iPad, Kindle, Smartphone oder sonstwas in die Hand geben. Bücher nur noch online im eigenen oder fremden Shop bestellen. Erfahrung sammeln als Leser. Sich aktiv in die Rolle der heutigen und zukünftigen Kunden versetzen. Als tägliche Pflichtübung für alle.

Damit geht dann einher, jeden Tag wieder zu überlegen, wie mit online und eBook usw. mehr Geschäft gemacht werden kann. Physische Bücher (pBooks) muss man nicht mehr anpreisen. Die verkaufen sich von selbst; ich meine, deren form factor verkauft sich von selbst. Gefragt sind Ideen, wie mit pBooks online oder eben mit eBooks Geschäfte gemacht werden können. “Wie kann ich den nächsten Kunden motivieren, sein Geschäft demnächst mit mir online zu machen oder ein eBook zu kaufen?”, diese Frage sollte sich jeder Buchhändler bei jedem Kunden stellen. Nur so wird das Neue wirklich ernst genommen. [2]

Der Grossist libri macht es jedem Buchhändler leicht, einen online Buchshop zu betreiben. Nunnes kleines Bücher & Co ist dafür ein Beispiel, aber auch die große Mayersche Buchhandlung. Das ist ein schöner Anfang. Technisch haben Buchhandlungen zunächst also nichts auszustehen. Doch dann… Gerade ein Gelegenheitskäufer findet nur schwer den Weg zum online Buchladen eines kleinen Geschäfts. Amazon hingegen ist in jedermanns Kopf verankert. Mit einem Shop von libri fängt die kreative Arbeit der Umarmung der “neuen Medien” erst an. Darauf kann sich niemand ausruhen.

Idee #2: Fokus

Wer als Buchhändler das Heil im Multichannel sucht, wird sich und seiner Kundschaft untreu. Aus meiner Sicht führt der ehrliche Weg im Buchhandel daher nicht in die Breite, in die Diversifikation, sondern in die Tiefe. Spitzer werden, fokussieren, auf das Wesentliche konzentrieren, das, so glaube ich, sollte die Strategie der Stunde sein.

Worin liegt die Aufgabe des Buchhandels, genauer: des Buchladens? Früher ging es darum, Bücher schlicht zugänglich zu machen. Ohne ausgefeilte internationale Logistik und ohne umfassende, frei zugängliche Verzeichnisse war der Buchhandel das Nadelöhr zum Buch. Er hat es beschafft – mit oder ohne eigenes Lager. Er hat es gefunden in dicken Katalogen. Darüber hinaus hat er sogar bei der Auswahl beraten. Die Präsentation vor Ort war immer nur ein klitzekleiner Ausschnitt.

Beschaffung, Lagerung, Nachschlagen: das alles ist heute aber kein Problem mehr. Jeder kann das genauso gut wie der Buchhändler (oder sogar besser, je nach Enthusiasmus). Und das auch noch von zuhause aus.

Worum geht es also heute beim Buchladen? Es bleibt nur der Inhalt. Es geht nur noch um die Vermittlung von Inhalten unabhängig vom Medium. Inhaltsproduzenten müssen an Inhaltskonsumenten vermittelt werden. Die vornehme Aufgabe der Buchladeninhaber ist dieselbe wie die guter Gastgeber: sie stellen Menschen einander vor – und ziehen sich dann zurück.

Wenn die Zusammengebrachten einander interessieren, dann wird mehr daraus. Sie treffen sich nach der Party wieder bzw. der Leser kauft Inhalte des Autors. Wie, wo, wann, wieviel… das sollte Gastgeber wie Buchhändler egal sein. Sie haben ihren Job getan, wenn sie ein Angebot einem Bedarf zugeführt haben.

Und dafür sollen sie dann auch entlohnt werden. Dem Gastgeber ist Beifall gewiss, der Buchhändler verdient dafür Geld.

Der Buchladen der Zukunft sollte sich also genau darauf konzentrieren: Lesebedarf und Lesestoff zusammenbringen. Egal wie. Je genauer und verlässlicher, desto besser. pBook, CD, MP3, eBook… egal. Im Laden kaufen, online kaufen… egal.

Die Frage, die sich der Buchhändler jeden Tag stellen sollte ist: Wie kann ich die Inhalte, die es gibt, die sich jeden Tag vermehren, interessierten Lesern zuführen? Alles ist erlaubt. Alles kann in Frage gestellt werden.

Schon lange hat der Buchhandel ja erkannt, dass es besser ist, Kunden beim Stöbern zu unterstützen. Statt von der Kasse aus zu rufen, “Bitte das Buch vorsichtig behandeln!” lieber noch einen Stuhl unter den Kunden schieben und ihn zum Weiterblättern animieren. Vor 30 Jahren wäre das in Deutschland noch undenkbar gewesen – außer in einer Bücherei. In gleicher Weise könnte anderes bisher Undenkbares aber auch Realität werden:

Beispiel Probekauf: Warum nicht noch einen Schritt weitergehen und Kunden Bücher mit nach Hause geben? Sozusagen Kauf auf Probe. Bei Nichtgefallen kann das Buch innerhalb von 48 Stunden zurückgebracht werden. (Mit Umtausch kann man sich soetwas als Kunde natürlich heute schon erschleichen. Deshalb vergibt sich der Buchhandel nichts, diese Möglichkeit als Dienstleistung offiziell anzubieten.)

Beispiel Serienabo: Es gibt zunehmend Autoren, die Buchreihen schreiben. Da tritt immer wieder derselbe Protagonist auf oder sie drehen sich ums selbe Thema usw. Wer Dona-Leon-Fan ist, der will wahrscheinlich all ihre Bücher lesen, dito wer Fan von Inspektor Wallander ist oder Kay Scarpetta mag. Warum also als Buchhandel nicht ein Abo auf Bücher solcher Reihen anbieten? Ja, ich weiß, dass es eine Buchpreisbindung in Deutschland gibt. Ein günstiger Abopreis wird deshalb wohl schwer bis unmöglich sein. Doch mit Kreativität lässt sich da doch etwas machen, denke ich. Lesern geht es nicht immer um den Preis. Sie wollen Bequemlichkeit, sie wollen Aufmerksamkeit. Ich würde mich freuen, wenn der Buchhändler meiner Wahl mir versichern könnte, mir z.B. jedes Buch von Martin Suter bei Erscheinen als Taschenbuch sofort zurückzulegen, mich zu informieren oder mir sofort zuzuschicken als Probekauf. Wenn dann noch jedem Buch eine kleine Aufmerksamkeit beiläge… Was wollte ich mehr? Das Abo brächte mir doch schon Ruhe und Gewissheit, kein Buch zu verpassen.

Beispiel Kontextkontakt: Man kann Bücher einfach nur so lesen – oder man kann in sie eintauchen. Mein Eindruck ist, dass das immer mehr Menschen wollen. Sie lieben es, sich in andere Welten zu begeben. Warum diesen Trend nicht aufgreifen? Ich fände es ausprobierenswert für Buchhändler, zusammen mit Reiseveranstaltern Angebote zu Büchern zu erarbeiten. Beispiel: Für Dona Leon Fans die Venedig Reise zu den Originalschauplätzen der Bücher inkl. Treffen mit der Autorin. Oder für Kay Scarpetta Fans eine Führung durch die Rechtsmedizin. Oder für Fans von Fantasy-Büchern Rollenspielabende. Oder, oder, oder. Das wären dann keine direkten Buchangebote mehr, aber es ginge immer noch um den Inhalt, weil sich diese Angebote Kontakt zum Kontext des Inhalts böten. Der kann im Buchladen oder außerhalb stattfinden. Bücher kann man lesen – doch Bücher haben das Potenzial für mehr. Ihr Inhalt ist immer nur Ausgangspunkt. Am Ende will der Leser ein Erlebnis. Das ist nicht anders als bei Fußball, Musik, Film, Autokauf. Es geht immer ums Erlebnis, um Gefühle. [3]

Beispiel Rückkauf: Wenn schon pBook, warum dann als Buchladen nur einmal daran verdienen? Wäre es nicht toll, wenn man sein pBook am Ende statt ins Regal daheim wieder ins Regal im Buchladen stellen könnte, um ein anderes mitzunehmen? Warum dafür in die Bücherei gehen, die irgendwie nie das aktuelle Buch hat, das man gerade lesen will? Der Buchladen nimmt heute schon Bücher ungelesen im Umtausch zurück. Da wäre es ein kleiner Schritt, sie in einem gewissen Zeitraum nach Kauf und in einem gewissen Zustand auch gelesen wieder zurückzunehmen – natürlich zu einem geringeren Rückkaufpreis. Das würde den Buchhandel auch an die zunehmende collaborative consumption heranführen. Die stellt nämlich die nächste Gefahr für alle dar, die neue Waren an jeden verkaufen wollen. Amazon macht es im Internet vor; dort schämt man sich nicht, neben neuen auch gebrauchte Bücher anzubieten.

Das sind vier Beispiele für eine Erweiterung der Dienstleistungspalette, ohne gleich zum Multichannel-Höker zu werden. Hier geht es ganz klar um den Inhalt, wenn nicht sogar ums Buch. Andere Ideen für Umsätze durch mehr Fokus lassen sich bestimmt finden. Für diese hier habe ich ja nur 10 Minuten gebraucht als Laie. Auch geht es nicht um den einen Knüller, sondern um eine Bandbreite an Angeboten neben dem pBook/eBook, ohne gleich auf Tassen und Frühstücksbrettchen ausweichen zu müssen. Warum bei Leseecke und Leseabend stehenbleiben?

Idee #3 Selektion

An ein Vollsortiment ist im offline Buchhandel gar nicht zu denken. Auch eine große Mayersche Buchhandlung kann nicht alles auf Lager haben oder auch nur präsentieren. Ich glaube deshalb, dass es zukünftig mehr denn bisher darauf ankommt, als Buchladen zu selektieren.

Die Selektion könnte entlang von Genregrenzen verlaufen: Krimibuchladen, IT-Buchladen, SF-Buchladen usw. Sie könnte das Alte auswählen (Antiquariat) oder das Neue: Warum nicht ein Buchladen, der von allen Verlagen immer und ausschließlich nur das Neuste hat? Und ich meine wirklich nur das Neueste. Für einen begrenzten Zeitraum, z.B. 3 Monate. Oder man schießt sich auf die Klientel in einem Quartier ein?

In jedem Fall gehört zur gezielten Selektion, die wirklich Mut hat, Titel wegzulassen, eine echte Kompetenz. In Bezug auf die Selektion muss der Buchhandel kundig sein: Autoren kennen, Empfehlungen aussprechen können, abgrenzen können. Wie beim Outdoor-Laden käme es dafür nicht auf eine formale Ausbildung an, sondern auf Enthusiasmus und Erfahrung.

Wenn der Buchladen aufgrund seiner Selektion und seines Fokuses mir helfen kann, zu neuen spannenden Titel in jedem Format zu kommen, dann bin ich als Leser begeistert. Das kann im persönlichen Gespräch geschehen oder durch eine besonders hilfreiche “Regallandschaft” oder durch eine eigene “Suchmaschine”… egal.

Der Buchhandel, der 2 Regale Krimis, 1 Regal Kinderbücher, 1 Regal SF, 4 Regale allgemeine Romane usw. hat, wird wohl leider keine Zukunft haben. Ihm fehlt die klare Selektion, ein deutliches Kompetenzprofil. Nicht, dass er keine Kunden fände, aber ich glaube nicht, dass sie ihm reichen können. Ich wüsste einfach nicht, was ich von ihm erwarten soll als “das Übliche”, d.h. 95% das, was ich auch bei Thalia und Amazon sofort angeboten bekomme. So ein Sortimentsdurcheinander wird zukünftig nur immobile Leser befriedigen, die quasi auf diesen Buchladen angewiesen sind.

Für mich liegt die Zukunft des Buchhandels aber nicht bei denen, die nicht anders können, sondern bei denen, die gezielt einen Buchladen aufsuchen, weil sie anders können, aber nicht anders wollen. Sie wollen in das Geschäft, weil das Geschäft ihnen unwiderstehliche, womöglich einzigartige oder zumindest sehr persönliche Angebote macht. Kunden von Buchläden wollen keine Bücher mehr – also Seiten zwischen Pappdeckeln –, sondern “Leseerlebnisse” rund um Inhalte. Und da es von denen potenziell viele gibt, freuen sie sich, wenn sie auf dem Weg dahin Gleichgesinnte treffen und mit Leuten zu tun haben, die sie wirklich verstehen. Je undefinierbarer die Selektion einer Buchladens aber ist, desto weniger ist zu erwarten, dass ein solcher Kontakt entsteht.

Idee #4 Präsenz

Den Buchhandel macht aus, dass man dort Bücher in die Hand nehmen kann. Ob er viele irgendwo auf Lager hat, interessiert nicht mehr. Ob er sie schnell besorgen kann, auch nicht. Im Laden interessiert mich, was ich dort vor Ort durchstöbern kann, was präsent ist und zwar in einer Form, die mir mehr bietet als ein online Bookshop.

Ich denke daher, dass Buchläden ihr Angebot in Bezug auf Buchpräsenz optimieren müssen. Heute sehe ich hohe Bücherberge mit demselben Titel. Warum? Weil man an Leser denkt, die das Buch physisch sofort mitnehmen wollen. Dabei ist das doch nicht mehr das Problem. Jeder kann das Buch morgen in seinem Postkasten haben oder in 30 Sekunden auf seinem eReader.

Mir wäre lieber, die Buchläden würden in den Regalen eine größere Vielfalt an Büchern präsentieren, statt vom selben Titel viele Exemplare. Auf die Spitze getrieben hieße das: Im Buchladen der Zukunft ist entsprechend seiner Selektion jedes Buch nur 1 Mal vorhanden – als Präsenzexemplar. Das kann ich mir vor Ort ansehen, aber nicht sofort mitnehmen. Stattdessen bestelle ich es an der Kasse und bekomme es morgen geliefert oder kann es mir runterladen. D.h. auf dem Präsenzexemplar ist auch klar ersichtlich, welche anderen Formate es gibt: ePub, PDF, Kindle, MP3, CD.

Auch nicht jedes Buch muss physisch komplett vorhanden sein. Wo es eBooks gibt, reicht im Regal eine Karte, die aussieht wie das Buch, um mir Geschmack zu machen. Oder ein Booklet mit einem Auszug. Davon würden viiiiel mehr ins Regal passen. Wenn ich dann mehr will, nehme ich mir einen der rumliegenden eReader und lese damit weiter im Buch, bis ich weiß, ob ich es haben will oder nicht. Natürlich kann ich es damit auch sofort über den online Bookshop des Ladens kaufen. [4]

Fazit

Soweit mal vier Aspekte mit Ideen für eine Zukunft des offline Buchhandels, d.h. von Buchläden. Wie gesagt, darunter ist keine Silberkugel. Es gibt keine Wunderwaffe zur Rettung des Buchhandels. Aber ich denke, Fatalismus ist fehl am Platze. Es lässt sich eine Menge tun, wenn man etwas kreativ ist und Mut hat.

Die Zukunft des Buchhandels liegt im Nebel. Nur soviel ist gewiss: das Terrain vor ihm ist tückisch und das bisher Bewährte gibt wenig Sicherheit für den weiteren Weg.

Deshalb halte ich es für wichtig, den Nebel nicht aussitzen zu wollen. Stattdessen besser frisch voran. In kleinen experimentellen Schritten. In den Nebel hinein. Oder gar selbst zum Nebel werden, mit ihm verschmelzen. Agieren statt reagieren. Niemand ist Opfer des Wandels durch das Internet – außer man macht sich dazu.

Bei diesem mutigen Voranschreiten dann auf eines vertrauen: dem inneren Kompass in Richtung Inhalt. Denn darum geht es: Inhalte, “Leseerlebnisse” zu vermitteln. Wer daran nicht interessiert ist und im Grunde alles verkaufen könnte, um “am Leben zu bleiben”, der ist schon heute kein Buchhändler mehr. Also fokussieren auf alles, was mit Inhalten zu tun hat.

Da dieser Bereich jedoch eher wächst denn schrumpft, braucht es wieder mal Mut: um sich in der Auswahl zu beschränken und in Bezug auf diese Auswahl echte Kompetenz aufzubauen. Mich zumindest wird in Zukunft der Bauchladenbuchhandel nicht mehr interessieren. Von allem ein bisschen…? Das kriege ich bei Amazon besser. Wenn ich in den Buchladen gehe, dann will ich, dass man mich anspricht, mich versteht. Rundum. In Bezug auf Inhalte und auch die Form. Wer da verlegen lächelt, wenn es um das Thema eBook geht, ist raus.

Für mich liegt daher die Zukunft des offline Buchhandels in der Präsentation einer profilierten Vielfalt. Ich will möglichst viel dort “begreifen” können im Laden. Denn was ich im Laden “ausprobieren” kann, dass kaufe ich eher. “Try before you buy.” Mitnehmen muss ich es nicht unbedingt und schon gar nicht als pBook.

Und nun kommt ihr, liebe Leser. Wer hat noch andere Ideen für den Buchhandel? Wenn der sich selbst schwer tut mit dem Wandel, können wir ihm vielleicht aus Lesersicht auf die Sprünge helfen.

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat… (Den trinke ich dann auch gern in einer Buchhandlung mit Coffeeshop ;-)

PS: Noch ein Hinweis dazu, wie die Veränderungen angegangen werden können in den Buchläden: gemeinsam. Der Buchhändler, der glaubt, er könne die Zukunft vorausdenken für seine Mitarbeiter (wenn er noch welche hat), verschenkt Ideenpotenzial. Alle müssen an einen Tisch, weil alle im selben Boot sitzen. Dabei ist dann alles erlaubt. Es gibt nur eine Pflicht: mutig nach vorne denken und Veränderungen ernsthaft ausprobieren. Ja, ich meine ausprobieren, d.h. zunächst nur für begrenzte Zeit implementieren. Nicht alles auf eine Karte setzen. Manche Aktion läuft dann vielleicht 4 Wochen, eine andere 3 Monate, eine dritte ein ganzes Jahr.

PPS: Wer als Buchhändler noch nicht damit angefangen hat, sollte übrigens schleunigst einsteigen ins Sammeln von Kundenadressen. Hier ist der Begriff Kanal tatsächlich wichtig: einen Kommunikationskanal zu den Kunden aufbauen. Briefpost, Twitter, Facebook, Email-Newsletter… egal. Dem Buchladen müssen die Kunden per Adresse bekannt sein. Die Zahl anonymer Buchkäufe muss minimal sein. Auch hier ist also Kreativität gefragt: Wie kann der Buchkäufer überzeugt werden, sich zu erkennen zu geben zumindest mit einer Email-Adresse?

Fußnoten

[1] Es sei denn, es geht um neue Formen, bei denen Leser noch Hilfestellung benötigen. Doch gerade da schwächelt der traditionelle Buchhändler. Ich kenne jedenfalls nur solche, denen das gute alte pBook so lieb ist, dass sie eigentlich keine eigene Erfahrung mit eBooks haben, geschweige denn Fans von eBooks wären.

[2] Oder auch die Kundschaft fragen, warum sie eben nicht online kauft oder kein eBook liest. Auch das zu wissen, ist wichtig. Wenn da die Antwort ist, “Weil ich ihren persönlichen Rat als Buchhändler schätze”, dann ist das toll und ein Hinweis darauf, was in Zukunft ausgebaut werden muss. Falls die Antwort jedoch lautet, “Ach, ich kenn mich mit Computern nicht so aus”, dann ist klar, dass dieser Kunde nur gezwungenermaßen im Laden steht; er kann nicht anders – und wird aussterben. Ihn zu bedienen, ist natürlich selbstverständlich. Irgendwie. Auf ihn die Strategie auszurichten, wäre aber verfehlt. Außer man sieht es als Marktlücke an, für “internet challenge people” einen Laden zu machen so wie in anderen Ländern Schreibstuben für Leseunkundige.

[3] Deshalb ist der Buchladen eigentlich auch gut aufgestellt. Er hat den persönlichen Kontakt zum Erlebnishungrigen. Amazon hat den nicht. Wenn der Buchhandel zum Multichannel wird, nutzt er diese Chance nicht. Eine Tasse zum Buch ist kein Erlebnis. Eine Harry-Potter-Party aber, die HP-Sondervorstellung in einem Kino, der Zauberkurs für HP-Fans im Laden, die HP-Reise nach Schottland, das Twitter Re-enactment eines Quidditch-Spiels jedoch… das sind Erlebnisse. Die kann man online nicht bestellen.

[4] Hier wird deutlich, dass der Buchhandel Hilfe von den Verlagen braucht. “Buchpräsentationskarten” und Booklets stellen sich nicht von allein her. Auch könnten pBooks schon gleich mit Hinweisen auf weitere Formate bedruckt sein. Für Neuerscheinungen gibt es manchmal vorab Booklets; warum aber nicht konsequent für alle Titel? Die können ja ganz einfach gehalten sein. Damit könnten die meisten Verlage mit ihrem kompletten Programm vor Ort in jeder Buchhandlung sein. Zum Anfassen.

Nachricht an den Buchhandel

Wir werden immer mehr. Ich meine die Leser wie ich, die Bücher elektronisch konsumieren wollen. Vor einem Jahr war das für mich noch kein so großes Thema. Ja, da habe ich auch schon ab und an eBooks gelesen; doch seitdem ich iPad und iPhone habe, hat sich das Verhältnis umgekehrt. Heute lese ich 90% elektronisch und nur 10% auf Papier. Ein Papierbuch kommt mir nur noch in dein Einkaufskorb, wenn ich es nicht vermeiden kann – oder mich die Nostalgie übermannt.

Unvermeidbar ist ein Papierbuch für mich, wenn es entweder einen Inhalt hat, der sich auf Papier einfach besser rüberbringen lässt (Beispiel Bildband oder Schmuckband) oder der Inhalt aus heute eigentlich unerfindlichen Gründen (noch) nicht als eBook verfügbar ist, er mir aber unmittelbar wichtig erscheint.

Ich lese heute tagsüber meist auf dem iPhone und abends im Bett auf dem iPad. Das iPhone habe ich immer dabei, so dass ich mein Lesebedürfnis immer befriedigen kann, ohne einen Buchberg mitzuschleppen. Vorteil Mobilität, Nachteil kleines Display.

Das iPad habe ich nur zur Hand, wenn ich es extra einstecke oder eben daheim. Auch hier habe ich meine ganze Bibliothek im Zugriff. Vorteil Displaygröße, Nachteil geringere Mobilität.

Auf dem Laptop lese ich nur noch, was mir während sonstiger Arbeit darauf gerade vor die Augen kommt. Wenn ich es aber nicht sofort lesen muss, verschiebe ich es auf iPad oder iPhone.

Und Papierbücher… die liegen bei mir nur noch herum. Ich habe noch größere Mengen, von denen mir einige auch lieb und teuer sind. Ich leere jetzt also nicht zwanghaft meine Regale. Doch über die Zeit werden sich die Reihen lichten. Fachliteratur veraltet oder interessiert mich nicht mehr; Belletristik ist eh nur selten wert, aufgehoben zu werden. 22 Kartons (ca. 1000 Bücher) hatte ich schon ausgelagert in ein “Archiv” im Keller; davon sind nun 11 Kartons durch Überschwemmung wertlos geworden und schon auf dem Sperrmüll gelandet. Die anderen werden wohl bald folgen – auch ohne Überschwemmung. Weitere 1000 stehen vor der Selektion. Regalplatz ist knapp; außerdem habe ich auf alles, was im Regal steht, keinen Zugriff, wenn das Regal nicht zur Hand ist. Und das ist recht häufig der Fall, weil ich viel auf Reisen bin.

Bottom line: Pads und Smartphones sind ein Gottesgeschenk. Ich liebe sie, weil sie mir das Lesen vereinfachen. (Spezielle Lesegeräte wie OYO eReader oder Kindle Reader halte ich für vorübergehende Verirrungen. In 5 Jahren sind sie vom Markt verschwunden.) Durch die Digitalisierung lese ich also nicht weniger, sondern mehr. Damit meine ich Bücher und nicht ganz allgemein, was mir so im Internet vor die Augen kommt.

Und nun, Buchhändler, hergehört: Ich benutze euch, ohne, dass ihr davon etwas habt.

Klingt hart, ist aber so. Ich gehe gern in Buchläden. Da lässt sich so schön stöbern. Ein Buch anzufassen, darin zu blättern, Bücher ausgebreitet zu sehen, zwischen den Abteilungen einfach wechseln zu können… das ist toll. Ein Besuch im Buchladen ist immer total anregend, finde ich. Da schnappe ich ganz viele Leseideen auf.

Nur kaufen tue ich dort nichts mehr.

Wenn ich ein interessantes Buch im Buchladen sehe, dann scanne ich die ISBN mit der Amazon App. Die zeigt mir dann, ob es dafür ein Kindle-Buch gibt. Wenn ja, dann lege ich mir das in meine Amazon-Wunschliste. Wenn nein, dann schaue ich bei libri nach, ob es ein eBook (ePub oder PDF) gibt. Wenn ja, lege ich mir das dort auf die Wunschliste. Sollte es kein eBook (auf Deutsch oder Englisch) geben, dann merke ich mir die Papierbuchausgabe – und schaue nach einem eBook später mal, wenn ich es wirklich haben will.

Was hat der Buchhandel davon? Nichts. Er liefert mir nur ein nettes Ambiente und eine Form der Übersicht, wie sie mir kein online Shop bieten kann. Ich halte den Buchhandel, nein, besser: die physische Buchpräsentation, also nicht für überflüssig. Auf keinen Fall! Ich liebe Bücher zum Anfassen, Stöbern. Regale sind toll, um sich inspirieren zu lassen.

Nur weiß ich nicht mehr, warum ich dann so ein Papierbuch (pBook) dort oder überhaupt kaufen soll.

Papierbücher haben ein paar Vorteile. Aber sie haben auch eine Menge Nachteile. Die sollte man nicht versuchen, als Vorteile oder auch nur als notwendige Attribute von Büchern zu verkaufen.

Auf diese Nachteile der pBooks und die Vorteile der eBooks werden in den nächsten Jahren noch mehr Leser stoßen. Allemal, wenn die Verlage erkennen, dass eBooks ein Mittel zur Kostenreduktion und/oder Margensteigerung sind. Denn dann werden eBooks preisgünstiger werden. Das führt dann aber nicht zu weniger Umsatz, sondern zu mehr. Bei einem Fachbuch als e/pBook für 39,00 EUR und mehr überlege ich länger, ob ich es mir kaufe. Wenn das eBook dann aber nur noch 14,50 EUR kostet… dann überlege ich nicht mehr. Dann kaufe ich es, selbst wenn mich nur 50% oder gar 25% davon echt interessieren.

Mit eBooks bin ich sehr viel näher am Impulskauf als mit pBooks. Heute ist ihr Kauf schon leichter: ein Link, dem ich zu Amazon folge, ein Klick, mit dem ich kaufe, ein weiterer Klick und ich habe das Buch auf meinem Rechner. Das dauert 20 Sekunden. Dafür musste ich mich nicht aus dem Haus bewegen und noch nicht einmal warten.

Günstiger ist der Kauf allerdings noch nicht. Das hält mich manches Mal noch davon ab, drauf zu klicken. Kindle-Bücher, die mehr als ihr papierernes Pendant kosten, sind widersinnig und kontraproduktiv. Doch das ist ein Problem der Verlage, nicht des Buchhandels.

Bücher sind toll. Buchläden sind toll. Deshalb kaufe ich aber noch lange nicht im Buchladen. Das ist meine Botschaft an den Buchhandel. Ich nutze ihn gern, trinke auch mal ein Käffchen beim Stöbern – doch einkaufen tue ich nicht mehr im physischen Laden. Und damit bin ich sicherlich nicht allein.

Die schlechte Nachricht ist also, dass der Buchhandel an mir und vielen anderen nicht mehr mit seinem Hauptprodukt verdienen kann. Jedenfalls nicht so, wie in den letzten 200 Jahren. Umdenken ist also nötig. Besser schnell als langsam. Denn der breite Umbruch steht vor der Tür, wenn Smartphones wie Pads besser und preiswerter werden. Bisher sind iPhone und iPad ziemlich einsam in der Qualität, finde ich – aber noch recht teuer. Doch Android und WP7 schlafen nicht, sie zögern nur. In 2-3 Jahren sieht der Device-Markt sicher rosiger aus.

Wenn der Buchhandel dann nicht andere Angebote macht als eine billige Ecke mit ein paar abstrusen eReadern und 2-3 Büchern mit einer “Gibt es auch als eBook”-Banderole… dann wird es dunkel im Buchgeschäft.

Doch es gibt auch eine positive Nachricht: Ich und sicher auch viele andere lieben ja das Stöbern in langen, bunten Buchregalen. Wir haben also ein Interesse daran, dass es Buchläden weiterhin gibt. Wir möchten beides: bequem und preisgünstig mit unseren Devices lesen und (!) Bücher aufstöbern in angenehmer Atmosphäre.

Ich wünsche mir daher einen Dialog mit dem Buchhandel oder der ganzen Buchproduktionskette. Wo ist das Forum, in dem Leser, Buchhändler, Grossist und Verlage darüber diskutieren, wie für alle Beteiligten die Zukunft aussehen könnte?

Klar, es geht auch ohne Diskussion. Dabei wird es dann aber vor allem einen Gewinner geben: die Leser. Selbst wenn es radikal weniger Buchläden geben sollte, täte uns das nicht so weh wie den Buchläden selbst. Uns ist es relativ egal, ob wir Amazon oder libri unser Geld geben. Wenn wir aber unser “Stöbererlebnis” erhalten könnten, würde uns das noch besser gefallen.

Also, wann beginnt der Dialog zwischen der heute schon existierenden Zukunft der Leserschaft und dem Buchhandel? Wo ist der Buchhändler, der eBook-Leser wirklich ernst nimmt und uns ein unwiderstehliches Angebot macht? Apps wie “stories unterwegs” sind ja nett – deshalb kaufe ich aber kein pBook in dem Buchladen.

Und wann nehmen Verlage den Buchhandel als wertvollen Mittler zum eBook-Leser wahr? Derzeit sind die eBook-Margen marginal für den Buchhandel. Der ist also gar nicht motiviert, ein eBook statt eines pBook zu verkaufen. Er muss sich also quasi an die Planken des untergehenden Schiffs pBook klammern. Damit tun sich Verlage mittelfristig keinen Gefallen. Denn: Wenn der bunte Buchhandel vor Ort entfällt, konzentriert sich der Buchverkauf noch mehr auf die wenigen großen online Buchhändler, allen voran Amazon. Und die setzen dann die Daumenschrauben an. Ach was, das haben sie schon. Verlage sind also gut beraten, sich auch besser schnell als langsam mit dem lokalen Buchhandel zu verbünden zum Thema eBook.

Im Moment gehöre ich wohl noch zur Avantgarde der Buchleserschaft, wenn ich 90% als eBooks lese. Doch das ändert sich in den nächsten 5-10 Jahren. Ich würde mich deshalb freuen, wenn mir schöne Buchstöbererlebnisse auch darüber hinaus erhalten blieben. Noch ist es für den Buchhandel nicht zu spät. Ich hoffe, er kriegt die Kurve.

Design zur Diskussion gestellt

In der Software Craftsmanship Diskussionsgruppe geht es in einem Thread um die Frage, was denn Software Design sei oder Software Architecture. Die Antworten der Software Craftsmen sind für mich sehr überraschend. Hier ein Beispiel:

George Dinwiddie hat auf meine Frage also geantwortet, für ihn sei alles Design, was mit Entscheidungen zu tun hat während der Softwareentwicklung. Außerdem sei Architektur eine Sache, die habe nichts mit Softwareentwicklung zu tun, sondern mit Gebäuden.

Und Keith Brown, den wir für seine Bücher zu COM+ und Windows Security mögen, stimmt ihm zu.

Kann das sein? Ich zumindest kann kaum glauben, dass erwachsene Softwareentwickler so über ihre Zunft (es sind ja Software Craftsmen) denken.

Oder hier noch ein Beispiel:

Die Formulierung, auf Design und Implementation müsse man ständig gleichzeitig achten, hat er auch in anderen Postings der Gruppe benutzt. Allerdings ist er auf Nachfragen wiederholt eine Definition von Design schuldig geblieben. Auch mochte er noch nicht einmal Design gegenüber Implementation abgrenzen. Immer nur das Mantra, man müsse beides (und noch viel mehr) ständig im Blick halten.

Kann das sein? Immerhin ist das Ron Jeffries, einer der Gründerväter der Agilitätsbewegung. Und der mag als quasi schon fundamentalistischer Vertreter von TDD = Test-Driven Design (!) nicht definieren, was denn Design sei? Merkwürdig.

Gelinde gesagt bin ich verwundert. Was ist los in unserer Branche? Oder ist das nicht unsere Branche, sondern eben nur eine gewisse zeitgeistige Strömung? Hm… immerhin äußern sich hier prominente Vertreter unserer Kunst.

Oder verstehe ich da fundamental etwas falsch? Ich dachte immer, wenn man Begriffe benutzt, dann sollte man auch ziemlich genau wissen, was sie bedeuten. Wer also “Design” im Munde führt, der sollte eine Definition davon in Bezug auf unser Metier geben können. Dasselbe gilt für Architektur. Oder wer keine knappe Definition hinkriegt, der sollte zumindest typische Fragen benennen können, die zu Design oder Architektur gehören – und andere, die eben nicht dazu gehören. Aber auch das bleibt in dem Thread aus.

Ich bin also verwirrt. Aber vielleicht können Sie bzw. vielleicht kann mir die Leserschaft meines Blogs helfen?

1. Sind Software Design und Software Architecture nützliche Begriffe für unsere Branche?
2. Wenn ja, wovon sind sie abzugrenzen?
3. Wenn ja, was sind typische Fragen, die ein Software Design beantwortet?
4. Wenn ja, was sind typische Fragen, die eine Software Architecture beantwortet?
5. Wenn ja, was sind vielleicht Fragen, die beide eben nicht beantworten?
6. Wenn nein, warum nicht?

Ich bin gespannt, ob wir hier mehr Substanz für die Frage nach Relevanz und Definition dieser Begriffe zusammen bekommen.

PS: Jetzt ist noch dieser Beitrag zur Diskussion hinzugekommen:

Ron Jeffries spricht also für alle Craftsmen, wenn er sagt, sie glaubten an Design, haben jeder für sich eine persönliche Meinung dazu, was das wohl sei (“internal meaning of it”) und seien einfach zuversichtlich, dass diese vielen Meinungen ziemlich eng beieinander lägen (“close enough to the same thing”).

Leider lässt mich auch diese Äußerung wieder sprachlos zurück. Sehr öffentliche Figuren der Branche sind sich also nicht zu schade, ihre Arbeit auf unsausgesprochene Bedeutungen zentraler Begriffe zu gründen? Es reicht ihnen die Hoffnung, dass man in Diskussionen schon dasselbe meine? Und weil es nun schon ein halbes Jahrhundert so unscharf zugegangen sei, müsse man sich nun doch auch nicht mit expliziterer Definition quälen?

Nein, sorry, da komme ich nicht mehr mit. Hier verliert sich ein Zweig der Softwareentwicklung für mich in “Pseudowissenschaft”. Denn die beginnt, wo Behauptungen nicht falsifizierbar sind. Und Falsifizierbarkeit basiert auf klaren Definitionen.

Begrenzte Qualität – aber zackig!

Uncle Bob hat “crap code” den Kampf angesagt: “Craftsmanship over Crap” – zünftige Handwerksleistung soll für mehr Qualität in der Softwareentwicklung sorgen. Dagegen hat Nicolai Josuttis vor einigen Jahren den Gedanken geäußert, wir sollten endlich lernen, uns mit “crap code” abzufinden; er sei nicht zu vermeiden:

“So, when I say "Welcome Crappy Code", my point is not to force crappy code. My point is simply to face the reality. But, yes, you can consider my position as a view of resignation.”

Natürlich habe ich mich gegen eine solche Resignation gewendet. Nicht umsonst habe ich die Clean Code Developer Initiative mitgegründet. Ja, wir können “crappy code” aus der Welt schaffen! Wir müssen uns nur bemühen. CCD macht´s möglich.

Nun sind seitdem zwei Jahre vergangen und ich sehe die Welt ein wenig anders.

Es gibt viel Motivation in der Entwicklergemeinde, nicht länger “crap code” zu entwickeln. Die Zahl der Mitglieder in der CCD XING-Gruppe wächst ungebrochen. Das ist toll.

Ich glaube auch weiterhin daran, dass wir schlechte Qualität nicht fatalistisch hinnehmen sollten. Teams müssen besseren Code schreiben, wenn sie im Geschäft bleiben wollen. Und wir haben auch grundsätzlich die Kenntnisse, wie das geht, besseren Code zu schreiben.

Aber… ja, ich sehe da ein Aber. Der geballten Faust in der Tasche der Entwicklerschaft steht eine ökonomische und organisatorische und kognitive Macht gegenüber, die nicht zu vernachlässigen ist.

Softwarequalität (also innere Softwarequalität vor allem im Sinne von Korrektheit und Evolvierbarkeit) ist nur ein Wert unter vielen. So wie Ehrlichkeit auch nur ein Wert unter vielen ist.

Wo es aber ein Wertesystem gibt, also viele, auch noch konkurrierende Werte, da müssen Werte ausbalanciert werden. Wie in der Produktion muss das Optimum beim Ganzen eingestellt werden und nicht beim Teil.

Schon das bedeutet, dass wir nie zu optimaler innerer Qualität kommen werden. Sie wäre ein lokales Optimum, unter dem das Ganze leiden würde.

Dazu kommt, dass wir nicht einmal optimale Qualität herstellen könnten, wenn wir wollten. Wir verhalten uns in Bezug auf innere Softwarequalität nicht rational. Denn rational wäre, unsere Begrenzung durch Kosten bei ihrer Herstellung zu akzeptieren und danach abzuwägen.

Wir können nicht einmal rational entscheiden, weil neben ökonomischen und organisatorischen Gründen auch kognitive Gründe unsere Entscheidungen beschränken. Ich behaupte, dass wir nicht einmal wissen können, was die optimale Qualität wäre. Kein noch so langes Nachdenken und Diskutieren darüber würde uns zu einer eindeutigen Lösung bringen. Der Grund dafür liegt in der Volatilität der Anforderungen. In einer kleinen Serie zu den Gesetzen der Softwareentwicklung hatte ich dazu schon einmal etwas gesagt.

Es geht also nicht. Verabschieden wir uns von der Vorstellung hohe oder gar optimale innere Qualität herzustellen. Wir bewegen uns nicht im Bereich der Rationalität, sondern müssen unter Bedingungen Beschränkter Rationalität (Bounded Rationality) arbeiten.

Unser Ziel kann eingebunden in ein Netz von Werten nur eine genügend gute innere Softwarequalität sein. Wir müssen uns mit “good enough” bescheiden. Auf allen Ebenen: bei der Architektur, bei der Modellierung, bei der Implementierung. Immer kriegen wir nur “good enough” hin. Das sehe ich als Annäherung an Nicolais Standpunkt.

Also: Mehr Qualität, ja! Aber den Anspruch an die Qualität begrenzen.

Das bedeutet zum Beispiel, wir können uns das ganze Gerede über Eleganz sparen. Eleganz ist etwas für Leute mit viel Zeit. Eleganz ist Verfeinerung. Und damit gewinnt man keine Schlacht.

Ebenso können wir uns längliche Diskussionen über alle Prinzipien von Clean Code Developer sparen. Sollte die Methode auf dieser Klasse oder jener definiert sein, damit das SRP eingehalten wird? Solche Fragen müssen ohne Zweifel erörtert werden – doch am besten in einer Timebox. Wenn darüber nach 10 Minuten keine Einigung mit Argumenten erzielt werden kann, dann sollte der Code so bleiben, wie er ist. Die Zukunft wird zeigen, wer in der Diskussion Recht hatte.

Die Prinzipien und Praktiken von Clean Code Developer behalten ihren Wert – aber nun sehe ich noch eine Herausforderung, die darüber hinausgeht:

Wie kommen wir möglichst schnell zu einer “good enough” Softwarequalität? Eine Liste mit Werten und Prinzipien auf Kärtchen ist nicht genug. Gedruckt sind die nämlich geduldig. Und auch die Mahnung, man solle sich täglich um sie bemühen, ist geduldig. Im Tagesgeschäft ist das schwer. Und das nächste Refactoring ist immer weit. Und TDD ist auch nicht einfach.

Nein, ich glaube, wir müssen anders vorgehen, um schnell zu “good enough” zu kommen. Wir müssen das Schreiben der Software so verändern, dass quasi automatisch und ohne lange Diskussion “good enough” rauskommt. Alles, was nicht sofort beim Schreiben passiert, passiert nämlich tendenziell gar nicht.

Das hat TDD im Grunde schon begriffen – nur ist die Refactoring-Phase sehr unspezifisch.

Also: Wie können wir zügig begrenzte Qualität in unserer begrenzten Rationalität herstellen? Wie setzen wir uns sinnvoll Grenzen in der Entwicklung, um schlicht nicht mehr soviel falsch machen zu können?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Architekturvision braucht Visualisierung

Über den Begriff Architekturvision bin ich in letzter Zeit ein paar Mal gestolpert. Zuletzt in der “Hauszeitschrift” Ausgabe August/2011 von it-agile.

Es freut mich natürlich, dass das Thema Softwarearchitektur an Sichtbarkeit gewinnt. Doch irgendwie will mir nicht ganz schmecken, was da jetzt unter “Agile Softwarearchitektur” in Umlauf gebracht wird. In dem Topf wird schnell alles verrührt, was irgendwie im Umlauf ist: User Stories + TDD + DIP + CQRS, fertig ist die Architektursuppe. Hm… Aber darüber ein andermal mehr. Hier will ich mich auf die Architekturvision konzentrieren.

Auf Seite 27 des genannten Heftes findet sich eine Beispielarchitekturvision (ohne nähere Angabe einer Problemdomäne):

“1. Es handelt sich um eine Internetanwendung.
2. Als Programmiersprache wird Java verwendet und JavaScript für das Frontend.
3. Im Backend wird Spring als Dependency-Injection-Container verwendet.
4. Für die Persistenz wird ein relationales Datenbanksystem verwendet und Hibernate für die Anbindung an das Datenbanksystem.
5. Als View-Framework wird Spring Web MVC mit JSPs verwendet.
6. Quasar ist unser Architekturstil.”

Der Zweck dieser Architekturvision:

“In dieser sollten genau die technischen und architekturellen Eigenschaften des Produktes beschrieben sein, die sich im weiteren Entwicklungsgeschehen far nicht mehr oder nur sehr schwer ändern lassen.”

Die Architekturvision soll sich also mit nicht-funtkionalen Belangen der Aufgabenstellung befassen. Und sie soll sich auf Fixpunkte konzentrieren. Bei beidem stimme ich zu. Eine Architekturvision ist also von Natur aus auf einem hohen Abstraktionsniveau. Die Beispielvision konzentriert sich auf das Was und nicht auf das Wie. So weit so gut.

Was ist aber mit dem Warum? Das halte ich für sehr wichtig gerade bei Architekturentscheidungen. Der vorgestellte Architekturvision fehlt jede Begründung, warum die Entscheidungen so ausgefallen sind. Weder enthält sie eine Erklärung, noch enthält sie einen Kontext, aus dem eine Erklärung später abgeleitet werden könnte.

Laut it-agile ist eine Architekturvision eine simple Liste von Festlegungen. Das war´s.

Mir ist das zuwenig. Und auch die rein textuelle Fassung finde ich wenig hilfreich. Da gibt es zwar eine verbale Verortung von Technologien, doch letztlich muss sich jeder die Topologie des Systems zusammenreimen. Missverständnisse sind da vorprogrammiert.

Auch mit dieser Aussage stimme ich nicht überein:

“Folglich hängt der konkrete Umfang der Architekturvision von den Fähigkeiten des Entwicklungsteams ab.”

Das würde ja die Architekturvision von der Selbsteinschätzung eines Teams abhängig machen. Damit wäre letztlich jedes Team grundsätzlich legitimiert, die Architekturvision dünn zu halten, weil es sich einfach für erfahren und fähig hält. “Ach, das haben wir schon so oft gemacht. Das müssen wir jetzt nicht nochmal diskutieren und aufschreiben.” Ich höre sie schon die Teammitglieder, die alles lieber tun, als über eine Architekturvision zu diskutieren und sich dann auch noch festzulegen. Das ist doch einengend; wer weiß schon, was in der Zukunft kommt? Besser man spart die Zeit und hält sich alle Optionen offen.

Nein, mit so einer relativierenden Empfehlung bin ich gar nicht zufrieden.

Das soll natürlich nicht heißen, dass man Architekturvisionsdokumentenberge erzeugt. Doch ein wenig immer gleiche Systematik kann nicht schaden. Ich verstehe schon, dass die Architekturvision keine Doktorarbeit werden soll. Natürlich soll sie zügig hergestellt werden können. Dem dient aber die Reduktion von Missverständnissen. Und das kann erreicht werden, indem Sie sich eine kleine Checkliste für Architekturvisionen zurechtlegen. Die besteht für mich aus zumindest zwei Oberpunkten:

Architekturvision I – Das Big Picture

Zuerst sollten Sie sicherstellen, dass Sie das Big Picture vollständig im Blick haben. Darin betrachten Sie das zu realisierende Softwaresystem als Ganzes in seinem Umfeld.

Fragen Sie:

1. Wer benutzt das Softaresystem? Welche Rollen arbeiten damit, welche anderen Softwaresysteme benötigen seine Dienste? Es geht darum, wer von Ihrem Softwaresystem abhängig ist.

2. Wovon ist Ihr Softwaresystem abhängig? Auf welche Ressourcen greift es zu, seien das Dateien, Datenbanken, andere Softwaresysteme, Drucker, Maschinen usw.?

Mit diesen Information erstellen Sie ein erstes System-Umwelt-Diagramm:

Damit bekommt die Architekturvision eine erste grobe Form. Sie wird visuell, wie es sich für eine anständige Vision gehört ;-) So lässt sich eine Architekturvision auch viel besser kommunizieren – am Whiteboard oder auf einer PPT-Folie.

Daran hangeln Sie sich anschließend weiter, Rolle für Rolle, Ressource für Ressource. Zu jedem Umweltelement stellen Sie Fragen wie:

a. Mit welcher Technologie findet die Interaktion statt? Das können bei Rollen z.B. sein Desktop-Client, Smartphone App, Web-Client oder auch Webservice. Bei Ressourcen kämen z.B. in Frage ORM, Webservice, ESB.

a.1. In welchem Modus werden die Interaktionstechnologien betrieben, z.B. zustandslos/zustandsbehaftet, REST/SOAP, unterbrechungsfreie Verbindung usw.
a.2. Gibt es Vorgaben für das Format der Datenrepräsentation bei Rollen und Ressourcen? Dialogskizzen und Datenformate können wichtige Hinweise für Architekturentscheidungen sein. [1]

b. Welche nicht-funktionalen Anforderungen sind an die Interaktionen gestellt? [2]

b.1. Gibt es Geschwindigkeitsanforderungen (Performance)?
b.2. Gibt es Lastanforderungen (Skalierbarkeit)?
b.3. Ist die Interaktion abzusichern (Security)?
b.4. Soll die Interaktion eine bestimmte Form haben (Usability)?

Das sind nur einige nicht-funktionale Anforderungen, die in den meisten Fällen relevant sind. Andere könnten sein Internationalisierbarkeit, Austauschbarkeit oder Ausfallsicherheit.

Lassen Sie sich nicht irritieren, wenn Sie nicht zu allen Antworten gleich genau wissen, wie Sie sie genau umsetzen sollen. Darum geht es bei der Architekturvision nicht. Sie können sich für Internationalisierung eines WP7-Clients entscheiden, ohne eine Ahnung zu haben, wie das mit Sliverlight geht; oder Sie setzen auf REST-Kommunikation mit einer Ressource, auch wenn Sie noch nicht recht wissen, mit welchem API Sie das in der Software bewerkstelligen.

Bei der Architekturvision geht es um Entscheidungen für Prinzipien und Paradigmen und Techniken zur Bewältigung von nicht-funktionalen Anforderungen. Solange Sie beurteilen können, dass eine Entscheidungsoption in dieser Hinsicht etwas bringt, wählen Sie sie.

Je mehr Erfahrung Sie damit haben, desto besser natürlich. Hier haben Teams mit Übung natürlich einen Vorteil; sie können Entscheidungen schneller und besser fällen. Explizit fällen sollten sie sie aber nichtsdestotrotz.

Dokumentieren Sie anschließend Ihre Entscheidungen im System-Umwelt-Diagramm. Hier eine Umsetzung der Architekturvision aus dem it-agile Heft (inkl. einiger Angaben, die dort explizit nicht zur Architekturvision gezählt wurden, mir jedoch wichtig erscheinen):

Ist doch nicht schwer zu malen, so ein Diagramm, oder? Aber es bringt soviel mehr als eine simple Liste wie im Heft. Es macht Annahmen expliziter, es lässt sich besser kommunizieren und überblicken und es ist auch noch ausführlicher, ohne überladen zu sein. Das Diagramm kostet keinen Mehraufwand gegenüber einer Spiegelstrichliste. Also nehmen Sie den Kommunikations- und Erinnerungsvorteil mit.

Am besten fragen Sie sich bei jeder Entscheidung immer sofort: Wo in einem Diagramm verorte ich die Entscheidung? Wo hat die Technologie, das Paradigma, die nicht-funktionale Anforderung ihren Platz? Ich behaupte, dass Ihnen damit Architekturentscheidungen auch leichter fallen. Sie werden nämlich greifbarer.

Architekturvision II – Das System

Das System-Umwelt-Diagramm bietet allerdings noch nicht für alle Entscheidungen einen passenden Ort. Oben haben Sie sicher schon ein paar Punkte aus der Architekturvision vermisst.

Deshalb sollten Sie das System-Umwelt-Diagramm noch etwas verfeinern. Zoomen Sie hinein in das Softwaresystem und bestimmen Sie in einem ersten Schritt grob die beteiligten Maschinen und/oder Betriebssystemprozesse. Was läuft wo? Diese Frage sollten Sie beantworten.

Hört sich nach Detailarbeit an, aber mir geht es nicht um Details, sondern nur eine zunächst grobe Vorstellung und ausdrückliche visuelle Formulierung von Fixpunkten. Um eine erste Idee von der Verteilung Ihres Softwaresystems auf Maschinen und Prozesse zu bekommen, sollten Sie nicht lange nachdenken müssen.

Fällt es Ihnen leicht, ist alles in Butter. Detaillieren Sie das System-Umwelt-Diagramm. Fällt es Ihnen nicht leicht, können Sie überhaupt noch keine Architekturvision haben. Ihnen fehlen dann Informationen, um zentrale, “visionäre” Entscheidungen fällen zu können.

Für das Beispiel sähe das Systemdiagramm aus meiner Sicht so aus (Kleinigkeiten habe ich dazu erfunden, um die Vision etwas spannender/vollständiger zu machen) [3]:

Auch hier sind die Annotationen wichtig. Assoziieren Sie soviele Entscheidungen wie möglich mit distinkten Bildelementen. Lassen Sie sich von den Bildelemente sogar leiten. Nehmen Sie jede Linie, jeden Kreis als Anlass sich zu fragen: Was könnten hier für nicht-funktionale Anforderungen relevant sein? Müssen wir etwas jetzt entscheiden, weil es grundlegend und später schwer zu verändern ist?

Ja, das meine ich so: Nutzen Sie die obige Liste und die Bilder als Checkliste. Arbeiten Sie die Spiegelstriche ab und gehen Sie dann nochmal durch die Grafiken und schauen Sie, ob Ihnen bei diesem zweiten Durchlauf noch etwas einfällt.

Die Grafiken sind insofern nicht nice to have, sondern Denkhilfe. Ich garantiere Ihnen, wenn Sie solche Grafiken als Visionsdokumente an der Wand Ihres Teamrooms haben, fällt es allen leichter, sich an der Architekturvision auszurichten.

Bottom line: Architekturvision ist gut und agil. Wunderbar. Doch machen Sie sich das Leben leichter mit systematischem Vorgehen anhand von Checklisten. Nutzen Sie die “Kraft des Visuellen”, um das mentale Modell von Ihrer Software auch schon in einem frühen Stadium möglichst leicht im Team homogen zu entwickeln.

Vsisionen dienen der Kohärenz. Sie sollen Kräfte bündeln und auf ein gemeinsames Ziel ausrichten. Was könnte dem besser dienen, als ein wahrhaft sichtbares Ziel, also eine Visualisierung der Architekturvision?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Fußnoten

[1] Bei der Architekturvision sollte vor der Entscheidung eine Auslotung der Entscheidungsspielräume stehen.

[2] Je genauer und quantifizierter die Angaben, desto besser, z.B. bei Skalierbarkeit die Transaktionen pro Sekunde oder Benutzer pro Stunde oder bei der Performance die maximale Antwortzeit.

[3] Halten Sie sich übrigens nicht lange mit komplizierten visuellen Sprachen auf. Standardkonforme UML ist hier nicht nötig. Die visuelle Sprache, die ich hier und auch sonst benutze, besteht aus 4 Symbolen für Funktionseinheiten, Rollen, Ressourcen und Abhängigkeiten. Das war´s.

Test-Driven Unterstanding

Was ist es im Kern, das TDD ausmacht? Darüber habe ich anlässlich einer längeren Konversation mit Ron Jeffries in der Software Craftsmanship Google Group jetzt noch einmal nachgegrübelt.

TDD hatte bescheiden angefangen als Test-Driven Development. Da ging es darum, Code in einer bestimmten Weise zu schreiben, um ihn von vornherein korrekt zu hinzukriegen.

Doch dann wurde TDD befördert von einer Codiertechnik zu einer Entwurfstechnik für Code: aus dem "D" wie Development wurde eine "D" wie Design: Test-Driven Design [1]. Es ging nicht mehr nur um möglichst korrekten Code, sondern auch um möglichst gute Struktur.

Korrektheit und Strukturqualität sind unabhängig von einander. Sie können korrekten, aber schlecht strukturierten Code schreiben - oder sie können wunderbar strukturierten Code schreiben, der nicht korrekt ist.

Damit ein Werkzeug nützt, bedarf es nun jedoch nicht nur seiner Eignung, sondern auch einer Vorstellung vom Ziel, das Sie mit ihm erreichen wollen, würde ich sagen. Ein Pinsel ist zweifelsohne zweckdienlich, wenn man ein Bild malen will, doch im Pinsel steckt kein ästhetisches Gefühl und keine Intention.

Wie steht es nun in dieser Hinsicht mit TDD?

Die Eignung zur Herstellung von Korrektheit ist zweifelsohne vorhanden. TDD sorgt durch seine Regel red-green auf der Basis von KISS und kleinschrittigem Vorgehen nicht nur für korrekten Code, sondern auch noch für eine hohe Testabdeckung.

Auch die Vorstellung vom Ziel des Einsatzes ist klar: korrekter Code. Sie steckt in den Testfällen, die genau angeben, wann Code korrekt ist, nämlich dann, wenn er für gegebenen Input den erwarteten Output liefert. Die Qualität der Arbeit mit TDD hängt also von der Qualität der Testfälle ab.

Diesen Gedanken lege ich mal auf den mentalen Stack. Push().

Die Eignung von TDD zur Herstellung von gutem Design finde ich hingegen weniger offensichtlich. Sie basiert allein auf dem refactor Schritt am Ende der kleinen Iterationen. Schon das finde ich ein bisschen dünn, weil es dafür keine Kontrolle gibt. Wachsende Korrektheit lässt ist sichtbar machen: die Zahl der grünen Tests steigt und die prozentuale Testabdeckung bleibt auf hohem Niveau. Woran aber ist die (wachsende) Qualität des Designs ablesbar? TDD führt auch zu korrekten Ergebnissen mit hoher Testabdeckung ganz ohne Refactoring für besseres Design.

Es gibt also für den Designaspekt bei TDD kein oder zumindest kein so naheliegendes Messinstrument wie für die Korrektheit.

Und wie steht es mit der Zielvorstellung? Wohin, inwiefern soll denn Code, wenn der Test grün geworden ist, refaktorisiert werden? Woher kommt die Vorstellung davon?

Hier wird für mich das Eis sehr dünn, auf dem TDD sich bewegt. In TDD steckt keine Vorstellung davon, wie gutes Design aussieht und es bietet auch kein Messinstrument für gutes Design. Die Behauptung, TDD führe zu gutem Design liegt allein im schlichten Vorhandensein des Refaktorisierungsschritts. Der ist aber nicht mehr als eine Erinnerung daran, sich bei jeder Miniiteration einmal Gedanken darüber zu machen. Und das wird dann in der Realität dann auch so gehalten: man kann sich darüber Gedanken machen, muss es aber nicht. Oder wenn, dann weiß keiner so genau, wann man sich genug Gedanken gemacht hat. Es fehlt ja jeder Maßstab und die handfesten Tests bleiben eh grün.

Das bedeutet unterm Strich, dass die Qualität des Design nichts so sehr von TDD abhängig ist - Refaktorisieren kann man auch, wenn man nicht nach TDD vorgeht -, sondern von der Designkompetenz des TDD-Betreibers.

Korrektheit ist abhängig von der Codierungskompetenz, Strukturgüte von der Designkompetenz. Ich finde, das hört sich sehr naheliegend an.

Die Leistung von TDD für das Design besteht damit nur noch in der Mahnung, sich im Refaktorisierungsschritt darüber mal Gedanken zu machen. Das war's. Nicht mehr und nicht weniger tut TDD für gutes Design. TDD ist vollständig davon abhängig, dass sein Nutzer sich erstens für die Refaktorisierung Zeit nimmt und zweitens auch noch selbst eine Vorstellung davon hat, wohin er refaktorisieren will.

Nochmal, weil es so wichtg ist: TDD selbst legt überhaupt kein (!) Design nahe. Weder ein gutes, noch ein schlechtes.

Gutes Design entsteht durch eine Vorstellung davon im Spannungsfeld von funktionalen und nicht funktionalen Anforderungen aufgehängt in einem Netz von Prinzipien.

Einzig ist TDD zugute zu halten, dass es eben nahelegt, sich gutem Design schrittweise anzunähern. Eine Zielvorstellung bleibt es jedoch schuldig, ebenso eine Unterstützung bei der Messung, ob wie nahe man ihr gekommen ist.

TDD ersetzt also nicht den Aufbau von Designkompetenz. Ist die nicht vorhanden, hilft TDD nur marginal, wenn überhaupt, beim Design und deckt den Mangel nicht einmal auf.

Und wovon hängt die Qualiät eines Design ab? Klar, von der Designkompetenz. Genauso wichtig ist allerdings auch ein gutes Verständnis der Anforderungen sowie des Problems. Das sollte auf der Hand liegen. Wer nicht versteht, wofür er eine Lösung entwickeln soll, wird seine Lösung kaum angemessen strukturieren.

Pop(). Hier kommt der Gedanke vom Stack ins Spiel. Denn wovon hängt die Qualität des Testfälle ab? Ebenfalls vom Anforderungs- und Problemverständnis. Wer die Domäne hinter den Anforderungen nicht versteht, wer dafür keine Lösungsidee hat, der kann keine angemessenen Testfälle bestimmen.

Wie oft das der Fall ist und TDD es kaschiert, ist immer dann sichtbar, wenn TDD-Sitzungen mit Tests auf "Extremwerte" (z.B. Null oder Leerstring) beginnen. Das sind Verlegenheitstests, um ans Codieren zu kommen. Ihr Kundennutzen ist marginal. Sie verschieben die Notwendigkeit, sich mit dem Problem richtig auseinander zu setzen nur.

Ohne tiefes Domänenverständnis keine guten Testfälle, die die Implementation in kleinen KISS-Schritten vorantreibt.

Ebenso ohne tiefes Domänenverständnis kein gutes Design.

Und ohne Designkompetenz auch kein gutes Design.

Angesichts solcher Voraussetzungshürden frage ich mich, woher die Popularität von TDD rührt. Meine Erklärung: TDD wurde von Leuten erfunden und gepusht, die hohe Designkompetenz haben und einen Weg gesucht haben, die zügig im Code anwenden zu können, statt sich in Designsitzungen zu verlieren. Die Agilitätsgrundsätze lassen grüßen.

Und bei denen funktioniert TDD auch durchaus. Insbesondere bei Code Katas. Denn die werden mit gutem Beispiel von denen vorgeführt, die erstens das Kata-Problem durchdrungen haben und zweitens hohe Designkompetenz besitzen. Guten Sportlern helfen mentales Training und optimierte Sportgeräte. Grobmotoriker hingegen brauchen keine Hightech, sondern müssen ersteinmal Grundfähigkeiten entwickeln. Es gilt die Bedingung für die Möglichkeit hoher Leistung zu schaffen.

Dasselbe gilt bei der Softwareentwicklung. Damit TDD dem Schluss-D gerecht werden kann, müssen einfach zunächst die Bedingungen stimmen. Das, so scheint mir, ist aber seltener der Fall als man gern annimmt. Wo sollen Sie denn auch geschaffen worden sein, die Bedingungen? Wo wird hohe Designkompetenz systematisch vermittelt, die TDD zur Entfaltung bringen kann? Wo werden mentale Modelle gelehrt, die dann mit TDD anstreben kann?

Das Missverständnis besteht also darin, dass TDD diese Kompetenz vermitteln oder ihre Abwesenheit kompensieren würde.

Was bleibt dann noch von TDD-Anspruch?

Test-Driven Development hat unzweifelhaft Wert. Wir brauchen systematisch mehr Korrektheit für unseren Code.

Für ein Test-Driven Design ist aber mehr nötig; allemal da TDD kein Messinstrument für Designqualität bietet.

Zuallererst müssen auch die Testfälle gut gewählt werden. Sonst wird selbst die Herstellung der Korrektheit schwierig.

Und so komme ich zu dem Schluss: TDD kann nur etwas bringen, wenn man wirklich versteht, worum es geht und einen Lösungsansatz hat. Dann und nur dann kann sich Designkompetenz mit TDD noch günstiger als ohne entfalten.

Doch wie zu einem Verständnis von Problem und Lösung kommen?

Ich bin ja der Meinung, dass Nachdenken hilft. Nachdenken und eine Vorstellung vom Design einer Lösung im Kopf bzw. am Whiteboard entwickeln. Keine detaillierte, nicht auf Codeniveau, aber eine solide. Sie sollten das Zutrauen haben, die Lösung ohne große Probleme codieren zu können. (Was nicht bedeutet, dass Sie sich damit nicht verschätzen können. Aber das macht nichts. Das kompensieren die TDD-Minititerationen.)

Ab einem gewissen Puntk jedoch, wird Nachdenken zu theoretisch und man tut gut daran, es mit lauffähigem Code zu untermauern bzw. zu befördern. Das kann ein Spike sein oder eben testgetriebener Code. Wenn der kleinschrittig entsteht, nähert man sich der/einer Lösung in kleinen Schritten.

Hier bringt TDD etwas über die Korrektheit hinaus. Das letzte "D" würde ich dann aber ersetzen durch ein "E" für Exploration (TDE) oder ein "U" für Understanding (TDU). TD hilft der Korrektheit und dem Verständnis. Test-Driven Understanding ist ein einlösbares Versprechen, glaube ich.

Das hat dann allerdings eine Konsequenz für die Praxis der beliebten Code Katas: man sollte sie eher nicht wiederholen. Denn wenn man sie einmal verstanden hat, dann kann man die Entwicklung von Verständnis an ihnen nicht mehr üben. Das jedoch ist das Schwerste in der Softwareentwicklung, scheint mir. Eine Problemstellung wirklich durchdringen, kostet einfach Mühe und Zeit und braucht auch wieder gewisse Kompetenzen.

Coding Dojos scheitern weniger daran, dass die Regeln des TDD nicht beachtet oder Technologien falsch eingesetzt werden. Sie scheitern daran, dass das Problem ungenügend durchdacht wird - und die wie immer geartete Lösungsvorstellung auf wenig Designkompetenz trifft. Da kann dann TDD nichts retten.

Wer TD fürs Development einsetzt, d.h. für mehr Korrektheit, der wird leicht Erfolge erzielen. Wer TD fürs Understanding einsetzt, wird auch voran kommen. Wer jedoch animmt, Designkompetenz durch “Rituale” ersetzen und Verständnis wie Lösungsentwurf überspringen zu können, der wird von TDD frustriert bleiben. TDD ist keine Abkürzung.

Das Problem hinter TDD harrt also immer noch einer Lösung: Wie erhöhen wir in der Branche durchweg die Designkompetenz?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Fußnoten

[1] Auch wenn ich unterschiedliche Links zu TD-Development und TD-Design angegeben habe, unterscheiden sich die Beschreibungen nicht wesentlich. Im Rückblick lässt sich daher wohl schwer sagen, wann aus welchem Grund aus Development Design geworden ist. Aber vielleicht kennen Sie den Umbruchpunkt und können für ihn einen Literaturbeleg liefern?

Tägliche Codeproduktionsquote

Wieviel Code produzieren Sie eigentlich? Wieviele LOC pro Tag, wieviele LOC davon Produktionscode? Schätzen Sie mal. Sind das 100, 500, 1000 Zeilen (ohne Kommentare, automatisch generierte using-Anweisungen und ohne Tests)?

Habe gerade die Code-Review-Fibel von SmartBear gelesen. Darin ging es auch um LOC.

Empfohlen wird nämlich, pro Peer Code Review nicht mehr als 200+ LOC durchzusehen. Da frage ich mich, wie lang ein Entwickler an diesen durchzusehenden Zeilen gesessen haben mag.

Der Review sollte nicht länger als 60-90 Minuten dauern. Wieviel Zeit ist vorher aber in die Produktion der Sourcen geflossen? Weniger oder deutlich mehr?

Keine Ahnung. Aber ich rechne einfach mal:

Wenn 1 Entwickler pro Tag 200 LOC netto Produktionscode schreibt, dann kommen pro Woche 1.000 LOC heraus und bei 200 Arbeitstagen pro Jahr 40.000 LOC. Ein Team von 3 Entwicklern käme auf 120.000 LOC/Jahr, 5 Entwickler auf 200.000 LOC/Jahr.

Das finde ich nicht schlecht. Denn insgesamt sind das ja immer doppelt soviele LOC, weil Produktionscode natürlich testgestützt ist und Tests gut und gern 50% des Gesamtcodeumfangs ausmachen.

120.000 LOC oder 200.000 LOC… das sind keine kleinen Projekte. Dazu kommt, dass eine Codeproduktionsquote von 200 LOC/Tag mit der Zeit immer mehr Kundenwert produziert. Je mehr Code schon existiert, desto eher können 200 neue Zeilen auf schon geschaffene Abstraktionen zurückgreifen.

200 LOC/Tag pro Entwickler mögen sich wenig anhören. Und natürlich kann man mehr “raushauen”, wenn man ein Code-Cowboy ist. Doch die 200 LOC/Tag, die ich meine, sind sauberer, d.h. verständlicher, evolvierbarer und gut testabgedeckter Code. Solche 200 LOC/Tag pro Entwickler konsequent produzieren, finde ich daher völlig akzeptabel.

Dabei fällt mir die Clean Code Developer School ein, deren 5. Staffel wir vor ein paar Wochen abgeschlossen haben. Darin unterrichten wir den Stoff an vielen Projekten (AppKata würde ich sie heute nennen). Und jedes Projekt durchlaufen wir nach einem systematischen Prozess, zu dem mindestens gehören: Anforderungsanalyse, Feature Slicing, Modellierung, Implementierung, Code Review.

Pro solcher Iteration produziert jeder Teilnehmer ca. 50-80  LOC Produktionscode, schätze ich mal. Und pro Tag durchlaufen wir meistens 2 Iterationen. D.h. unter Lernbedingungen, wo alles etwas langsamer geht, kommen schon 100-150 LOC raus.

Der Review dauert je nach Übung 30-60 Minuten. Dabei schauen wir den Code von 1 bis 3 Teilnehmern unter verschiedenen Gesichtspunkten an.

Und am Ende des Tages? Da sind wir zufrieden. Das finde ich sehr wichtig. Wir wissen einfach, dass wir Qualität produziert haben. Wir schließen immer mit einer Retrospektive und reflektieren unsere Arbeitsweise.

Wenn ich das nun auf ein Projekt übertrage, dann scheinen mir 200 LOC/Entwickler netto Produktionscode als Tagesquote ein brauchbarer Wert.¹ Der Code lässt sich dann nämlich nicht nur schreiben, sondern auch noch in einem Code Review lesen.

Der Rhythmus könnte z.B. so sein: Heute 200 LOC produzieren, morgen die 200 LOC annotieren (d.h. als Produzent reflektieren, s. Code Review Fibel) und Peer Code Review durchführen. Dann hat man einmal drüber geschlafen und schaut seinen Code am nächsten Tag frischer an. Das trägt sicher positiv zur Fehlerfindung bei. Was heute geschrieben wurde, ist morgen durchgesehen und bereit für die QS. Jeden Tag wieder. Konsequent. Systematisch.

Zuwenig Code sind 200 LOC/Tag/Entwickler also nicht.

Aber sind sie vielleicht zuviel? Ja, in manchen Projekten mögen Entwickler nicht einmal auf soviele LOC/Tag kommen. Immer ist irgendwas, das sie davon abhält: Meetings, Support, Dokumentation schreiben… Die Ablenkung lauert überall.

Sollte das der Fall sein, dann haben Sie nun mit den 200 LOC Codeproduktionsquote für den Tag einen Wert, über den Sie mit dem Chef reden können. Solange die “Produktionsverhältnisse” nicht so sind, dass Sie jeden Tag 200 LOC netto Produktionscode schreiben, solange müssen die Verhältnisse noch verbessert werden. Aber Achtung: Dazu gehört natürlich auch der tägliche Code Review!

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…

Fußnoten

¹ Sollten Sie mehr Code “raushauen” können pro Tag, dann müssen Sie sich fragen, wann dafür Code Review stattfinden soll. Ich bezweifle, dass Sie bei einer höheren Produktionsquote systematisch mit Code Reviews die Qualität steigern können.