Follow my new blog

Dienstag, 26. Juli 2011

Nachricht an den Buchhandel

imageWir 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.

imageUnd 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.

imageBottom 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.

imageWenn 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.

imageAuf 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.

imageWenn 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.

Montag, 18. Juli 2011

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:

image

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:

image

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:

image

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.

Sonntag, 10. Juli 2011

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…

Samstag, 9. Juli 2011

Architekturvision braucht Visualisierung

imageÜ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.

imageLaut 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:

image

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):

image

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]:

image

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.

Freitag, 8. Juli 2011

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?