Die Aschenputtel-Strategie - Ein 80:20-Kriterium für neue Technologien und Konzepte

Wie und wann entscheiden Sie sich eigentlich für den Einsatz einer neuen Technologie oder eines Konzeptes? Wann legen Sie mit IronPython los? Wie entscheiden Sie, ob Sie den Entity Framework benutzen?

Aschenputtel konnte die Tauben um Entscheidungshilfe bei der Sortierung von Linsen bitten - "die Guten ins Töpfchen, die Schlechten ins Kröpfchen". Sie hingegen sind auf sich allein gestellt. Wie entscheiden Sie zwischen Gutem und Schlechtem, d.h. Lernwürdigem und dem, was Sie ignorieren?

Diese Frage sprang mir bei der Lektüre von Kevin Hazzards Serie über F# in den Sinn. F#, Microsofts funktionale Programmiersprache, nimmt gerade Anlauf, um in den Mainstream der Programmierung zu springen. Aber lohnt sich der Lernaufwand für F# wirklich? Dito beim ADO.NET Entity Framework. Dito für die Windows Workflow Foundation. Dito für alles Neue, Vielversprechende.

Wir leben im Überfluss. An Optionen für unseren Werkzeugkasten mangelt es nicht. Und wenn wir die Qualität unserer Arbeit ständig steigern wie auch produktiver werden wollen, dann tun wir gut daran, immer wieder Neues zu lernen. Ohne eine Strategie ist es jedoch schwer, aus dem Überfluss für uns Geeignetes auszuwählen. Deshalb schließen viele Entwickler die Augen und blenden den Überfluss auf Jahre aus - um dann bei einem Jobwechsel mit einer dramatisch veränderten Welt konfrontiert zu werden, die es ihnen sehr schwer macht, auf die aktuellen Züge aufzuspringen. Eine Vogel-Strauß-Strategie ist also denkbar ungeeignet für mittel- und langfristigen Erfolg in unserer Branche.

Eine Fahne-im-Wind-Strategie bringt es andererseits aber auch nicht. Niemand tut gut daran, möglichst immer beim Neuesten schnellstmöglich dabei zu sein. Bleeding edge technology heißt nicht umsonst so: an forderster Entwicklungsfront kann man sich leicht schneiden und viel Zeit in den Sand setzen.

Von welcher Strategie können Sie sich nun aber helfen lassen? Ich nenne sie mal...

Die Aschenputtel-Strategie - oder: 80:20 einmal anders

Aschenputtel hat zwar nicht diese Strategie angewandt, aber sie hatte zumindest eine Strategie (der Delegation) und war damit organisierter als viele Softwareentwickler, wenn es um die Trennung des "Guten" vom "Schlechten" geht.

Meine Idee einer Strategie lautet nun ganz simpel:

Etwas Neues ist "gut" oder "lernwürdig" oder "adaptionswert", wenn es bei 80% der Projekte zu 20% "Einsparungen" führt.

Die 80:20 habe ich natürlich aus Effekthascherei gewählt :-) Das Verhältnis ist durch die Pareto-Verteilung zu Ruhm gekommen und insofern ein eye catcher. Letztlich geht es mir aber nicht um 80% der Projekte, sondern nur um einen genügend großen Prozentsatz, den jeder selbst für sich bestimmen muss. Ich halte nur nichts davon ihn viel höher zu setzen. Wer nach Neuem sucht, dass in 100% oder 95% der Fällen "der Bringer ist", wird kaum fündig und somit de facto zum Vogel Strauß.

Auch die 20% sind nur ein Anhaltspunkt. Die Einsparungen sollen einfach deutlich sein. Sie sollen sie nicht mit der Lupe suchen müssen. Sie sollen nicht in zufälligen Fluktuationen untergehen und auch nicht unterhalb der Messbarkeitsgrenze liegen. Da sich die Branche mit Messungen eh schwer tut, ist also ein Prozentsatz nötig, der Verbesserungen mit dem bloßen Auge erkennbar macht. Sie müssen sich auch dem oberflächlichen und gelegentlichen Betrachter recht leicht erschließen.

Nochmal etwas laxer und im Ganzen formuliert: Wenn Sie auf eine neue Technologie stoßen, einem neuen Konzept begegnen, dann fragen Sie sich: Bringt mir diese Neuerung in einem großteil meiner Projekte einen deutlichen Vorteil?

Hört sich eigentlich einfach an oder gar normal. Fragen Sie sich das nicht ohnehin? Durchaus - aber dennoch glaube ich, dass diese ausdrückliche Formulierung noch etwas bringt.

1. Durch diese Formulierung wird betont, dass eine Neuerung nicht immer, sondern nur häufig einen Vorteil bieten muss. Allzuleicht verfallen Softwareentwickler und ihre Chefs nämlich in ein Optimierungsdenken, dass mit weniger als 100% kaum zufrieden ist. 100% oder Perfektion sind aber für den Fortschritt und gerade für Lernprozesse eine zu hohe Marke.
2. Die ausdrückliche Formulierung macht nicht nur dem Betrachter etwas bewusst, sondern ist eine Mahnung an den Anbieter der Neuerung. Sie führt ihm nämlich die Pflicht vor Augen, den Betrachtern es möglichst schnell und einfach klar zu machen, wieviele und wie sie Vorteile bietet. Als Betrachter will ich nämlich nicht lange rumrätseln, ob und wie F# oder das Entity Framework vielleicht und eventuell helfen könnten. Ich will konkret und mit Bezug auf meine bisherige Praxis erfahren, warum und wie sie mir etwas bringen.

Gerade der zweite Punkt vernachlässigen die Beseelten aber häufig. Wer über F# oder SQL Service Broker oder MSF oder Software Factories schreibt, ist selbst meist so davon überzeugt, dass er sich in allgemeinen und abstrakten Beschreibungen der visionierten Vorteile ergeht - dabei aber den noch nicht beseelten Betrachter aus den Augen verliert.

Gerade auch bei der oben erwähnten F#-Serie ist mir das aufgefallen. Kevin ist so begeistert, dass er bei aller Mühe mir in 4 Folgen seiner Serie nicht deutlich gemacht hat, warum ich F# lernen sollte. (Und das, obwohl ich schon ein F# Buch im Schrank stehen und zu 2/3 gelesen habe.) Er kommt einfach nicht auf den Punkt. Er greift nicht an den vorteilhaften Differenzen zu C# an. Er kehrt nicht den Mehr(!)wert heraus.

Information ist "ein Unterschied, der einen Unterschied macht" - so definiert es Gregory Bateson. Damit ich einen positiven Unterschied in meiner Arbeit durch etwas Neues realisiere, muss mir sein "Verkäufer" aber erstmal einen positiven Unterschied zu meinen bisherigen Vorstellungen und Gewohnheiten deutlich machen. Welcher Unterschied macht also welchen Unterschied? Zum Beispiel: Was an F# im Unterschied zu C# macht also welchen Unterschied in meiner Arbeit aus?

Es genügt nicht, nur die ersten Unterschiede aufzuzeigen. Implizite strenge Typisierung, Funktionen als Werte, Currying... das sind Unterschiede zu C#. Die werden auch allerorten beschrieben. Doch welchen Unterschied machen Sie für meine Arbeit. Nicht dass ich sie anwenden könnte, dass sie überhaupt da sind, motiviert Sie oder mich zum Einsatz von F# - es sei denn, wir sind sehr akademisch interessiert. Nein, der Unterschied muss einen spürbaren (20%) Unterschied in unserer täglichen Arbeit machen.

Irgendwas muss ich durch den Wechsel von A auf B, von C# auf F# (oder Python oder Ruby), von ADO.NET auf das Entity Framework (oder NHibernate oder OpenAccess) usw., irgendwas muss ich durch diesen Wechsel "einsparen". Ja, ich denke, es geht immer ums Sparen. Woanders mag es ums Schöne oder Interessante gehen, aber in unserer Branche geht´s vor allem ums Sparen. Das Neue soll uns Zeit sparen oder es soll uns Ressourcen sparen.  Die Zeit kann beim Entwurf oder bei der Herstellung von funktionalen wie nicht-funktionalen Eigenschaften oder bei der Produktion oder der Wartung gespart werden. Oder wir brauchen zur Entwicklungszeit oder zur Laufzeit weniger Ressourcen wie Prozessorleistung oder Speicherplatz oder Bandbreite.

Also: Was, wann und wieviel spare ich, wenn ich auf F# usw. umsteige?

Das (!) ist die Masterfrage, die die "Verkäufer" von Technologien und Konzepte zu allererst und klar und verständlich und ohne Umschweife zu beantworten haben. Natürlich geht das nicht immer in so harten Zahlen wie die 80:20 suggerieren. Aber die Mühe sollte man der Darstellung schon ansehen, diesem Ideal möglichst nahe zu kommen.

Anbieter sollten sich als Leitlinie bei ihren Darstellungen Fragen wie diese nehmen, die mir bei Lektüre einer Darstellung im Kopf herumgehen:

• Hilft mir das, um den Aufwand bei der Codierung um 20% zu reduzieren?
• Hilft mir das, um in 80% meiner Projekte deutlich mehr Fehlerfreiheit zu erreichen?
• Hilft mir das, um den Wartungsaufwand um 20% zu reduzieren?
• Hilft mir das, um 80% meiner Software deutlich länger attraktiv am Markt zu halten?
• Hilft mir das, um 20% mehr Performance oder Skalierbarkeit zu bieten?

Vorstellungen von Neuem, die mir diese und ähnliche Fragen nicht beantworten, sind in nicht-akademischen Kreisen oder außerhalb der Freizeitlektüre nutzlos. Wer mich motivieren will, der muss mir klar machen, dass sein Angebot diese Leistung erbringt. Wenn ich nicht in 80% meiner Projekte 20% Verbesserung in einem Bereich spüre, der mir überhaupt bewusst ist (oder lohnenswert bewusst gemacht werden kann), dann bin ich nicht motiviert.

Insofern werde ich mich erstmal nicht weiter mit F# oder Python oder dem Entity Framework beschäftigen. C# und db4o/OpenAccess/Persistor.NET sind derzeit gut genug. Mir konnte bisher nicht klar gemacht werden, dass das Neue irgendetwas um 20% verbessert.

Noch nicht - aber das kann natürlich anders werden. Beobachten werde ich den Markt weiterhin. Irgendwann mag eine Botschaft auftauchen, die auch mir den 20%-Gewinn von F# & Co deutlich macht.

Fazit

Mir und Ihnen als Beobachter des Marktes kann ich nur empfehlen, die Aschenputtel-Strategie bewusst anzuwenden. Fragen wir uns bei allem, was wir lesen/sehen, ob es danach ins Töpfchen oder Kröpfchen gehört.

Den Anbietern von Neuem (manchmal bin ich das auch selbst ;-) kann ich nur empfehlen:

• Kennzeichnen Sie Ihre Angebote als "motivierend" oder "informierend" oder "unterhaltend". Bei motivierenden Inhalten müssen die 80:20-Fragen klar beantwortet werden. Bei informierenden Inhalte ist das nicht mehr in der selben tiefe nötig, dann bin ich ja schon motiviert, wenn und weil ich den Beitrag lesen. Dann geht es nicht mehr ums Ob und Warum, sondern das Wie. Bei unterhaltenden Angeboten schließlich geht es um, nun, Unterhaltung. Da will ich keine "Kaufentscheidungen" treffen oder etwas lernen.
• Holen Sie Ihre Zielgruppe(n) da ab, wo sie heute stehen. Im Zeitalter des Überflusses geht es nicht mehr darum, ein Vakuum zu füllen. Wir alle haben schon Lösungen für die meisten Probleme, die mehr oder weniger gut gehen. Ihr Angebot muss sich also nicht nur gegen die Wettbewerber, sondern vor allem etablierte, schon vorhandene Technologien/Konzepte (oder schlicht Gewohnheiten) durchsetzen. Am besten zeigen Sie, wie etwas mit dem Neuen geht, das bisher nicht ging, aber gehen sollte. Oder Sie zeigen, wie etwas, das heute schon geht, mit dem Neuen eben 20% "besser" geht (leichter, schneller, verständlicher, skalierbarer usw.).
• Bedenken Sie, dass Ihre Zielgruppe(n) selten vor der Entscheidung zwischen dem "Einkauf" von Neu.A oder Neu.B stehen. Es geht meistens um Alt.A oder Neu.B. Soll überhaupt etwas anders gemacht werden? Nicht wie anders, sondern ob anders, ist die oft erst durch die Lektüre eines Angebotes aufgeworfene Frage.

Als Informations- oder Motivationsempfänger sind wir offen. Das ist sozusagen unser Angebot - letztlich auch, weil wir nicht anders können. Wir wollen und müssen schauen, wo wir etwas verbessern können. Sparen - so ganz allgemein - ist Programm in der Programmierung. Und nicht nur da.

Anbieter, oder genauer: Motivierer sollten das respektieren und auf den Punkt kommen. Klare Aussagen, klare Beispiele, statt Hype.

Zum Glück ist es mit der Aschenputtel-Strategie aber einfach, zwischen Fluff, Hype, Enthusiasmus und Reellem, Bedenkenswerktem, Wahrhaftigem zu unterscheiden.

Datenzugriff heute - Die Qual der Wahl beleuchtet

ADO.NET oder LINQ to SQL oder Entity Framework... was leisten eigentlich diese Datenzugriffstechnologien? War schon ADO.NET bei seiner Einführung ein rechter Brocken, den wir als cursorliebende Entwickler zu schlucken hatten, so ist die Datenzugriffswelt seitdem nicht wirklich einfacher geworden - aber vielfältiger. LINQ to SQL und Entity Framework versprechen zwar viel, wie stehen sie aber wirklich im Vergleich zu einander und mit ADO.NET da?

Etwas Ordnung in dieses Gemenge versucht dieser Tage ein Artikel im hierzulande recht wenig bekannten, aber nicht minder guten CoDe Magazine zu bringen. Unter dem Titel "Data Access Options in Visual Studio 2008" stellt Julia Lerman diese drei Datenzugriffstechnologien recht lesenswert nebeneinander. Der Artikel kann - obwohl ziemlich lang - das Feld zwar nicht komplett ausleuchten, doch er gibt einen guten Überblick, wie ich finde. Und das sogar ganz kostenlos in der online Version des Magazins.

Für knapp 20 EUR gibt´s das CoDe Magazine aber auch auf Papier ins Haus geliefert - um es ganz bequem im Lehnstuhl oder auch am Strand lesen zu können. Das gönne ich mir gern. (Und der Herausgeber, Markus Egger, ist ein Netter, mit dem man auf der VSone oder der ADC auch in Deutschland plaudern kann.)

Technologiedämmerung - Nur konstantes Beobachten hilft

Welche Technologien bringen eigentlich 'was? Wann lohnt es sich aufzuspringen? Diese und ähnliche Fragen höre ich immer wieder von Konferenzteilnehmern oder bei Beratungen. Sie sind Zeichen der Ratlosigkeit angesichts einer kaum mehr überschaubaren Zahl von technologischen Optionen. Wer eine Fachzeitschrift wie die dotnetpro liest, der hat deshalb Anspruch, dass sie ihn darüber informiere, was lohnt und was nicht lohnt.

Die Empfindung bei vielen ist jedoch, dass Fachzeitschriften solchem Informationsanspruch nicht gerecht werden. Sie verkünden nicht immer "die Wahrheit", d.h. sie scheinen nicht neutral gegenüber Technologien. Sie sagen nicht offen (oder nur viel zu selten), welche gut und welche schlecht sind.

Beispiel CORBA-Berichterstattung

Anlässlich eines Artikels mit dem Titel "The rise and fall of CORBA" sind mir die Eingangsfragen nun wieder eingefallen. Sicherlich haben in den letzten 10-12 Jahren viele Entwickler überlegt, "Soll unser Projekt auf CORBA setzen oder nicht?" Sie mögen sich dann den einschlägigen Fachzeitschriften wie dem OBJEKTspektrum oder JAVAspektrum um Entscheidungshilfe zugewandt haben. Andere Quellen mögen natürlich auch konsultiert worden sein. Aber nun... nun ist CORBA tot. Doch nicht nur das! CORBA hat auch - wie der Artikel resümiert - nie wirklich gut funktioniert. CORBA war zum Scheitern verurteilt.

Soviel weiß zumindest der geschichtliche Rückblick. Wie ist es aber heute? Welche Technologien und Ansätze sind das CORBA von morgen? Das würden alle Softwareentwickler gern so früh wie möglich wissen, um nicht ihre kostbare Zeit an Verlierer zu verschwenden.

Ich habe mir deshalb mal die Berichterstattung zum Thema CORBA im OBJEKT- und JAVA-spektrum angeschaut. Ganz grob nur, aber trotzdem mit einem interessanten Ergebnis, wie ich finde. Die folgende Grafik zeigt die Häufigkeit der Erwähnung von CORBA in Artikeln im Allgemeinen und den Artikelüberschriften im Besonderen über die Jahre.

In den Jahren 1994 bis 2000 nimmt die Berichterstattung zu. CORBA ist ein heißes Thema. Auf dem Gipfel Relevanz enthält fast jedes Heft einen CORBA-Artikel und in jedem zweiten ist CORBA auch noch im Titel erwähnt.

Doch dann verliert CORBA abrupt an Präsenz. Im Verlauf von 3 Jahren sinkt die Berichterstattung auf Null - und erholt sich danach auch nicht wieder. Insbesondere bleibt CORBA aus den Artikeltiteln verschwunden.

Was war geschehen? In den Jahren 2000 bis 2003  hatten SOAP-basierte Web Services und EJB 2.0 die Aufmerksamkeit der Berichterstattung. Sie haben der CORBA-Initiative das Wasser abgegraben und schließlich zu dem Urteil geführt, dass CORBA seine Versprechen nicht eingelöst hat und wohl auch nicht einlösen konnte.

interpretation der Berichterstattung

Jetzt zur Frage, wie ein unbefangener Leser dieser Zeitschriften die CORBA-Entwicklung hätte einschätzen sollen. Was boten OBJEKT- und JAVAspektrum für Hinweise?

Mein Eindruck ist, dass es keine wirklich kritische Berichterstattung gibt. Das hat nichts mit diesen beiden Zeitschriften zu tun, sondern ist endemisch. Kritische Berichte mit einer Überschrift wie "Die Nachteilte von Technologie X" sind anscheinend unattraktiv. So, wie die Bild-Zeitung vor allem über Negatives berichtet, so berichten Fachmagazine vor allem über Positives. Skandale, Gewalt, Sex verkaufen sich beim Massenpublikum der Boulevardpresse. Verheißungen, Erfolge, Hype verkaufen sich beim Fachpublikum. (Und ab und an auch Negatives wie Microsoft-Bashing.)

Kritik ist kaum explizit vorhanden. Implizit findet sie allerdings statt: Wie die Grafik zeigt, ist ab 2001 CORBA deutlich weniger ein Thema. Das ist ein erster Hinweis auf Nachteile bzw. ungenügende Vorteile. Ein noch deutlicherer Hinweis scheint jedoch die fast völlige Abwesenheit des Begriffs in den Artikelüberschriften. Wo CORBA nicht mehr in der Überschrift steht, da ist wenig oder gar kein CORBA drin. Bis 2000 fand CORBA in ca. 50% der Artikel den Weg in die Überschrift, nach 2000 im Mittel nur noch bei 10%.

In der Berichterstattung ist die Abwesenheit von Lob bzw. titelgebender Erwähnung die deutlichste Form von Kritik, wie es scheint.

Schlüsse

Natürlich wäre eine breitere Auswertung der Berichterstattung über CORBA und auch andere erfolgreiche wie erfolglose Technologien wünschenswert. Als anekdotische Analyse mit Motivationscharakter mag dieser Versuch dennoch aber gewissen Wert haben. So ziehe ich denn einmal folgende Schlüsse aus den Zahlen:

• Technologiedämmerungen werden nicht wirklich thematisiert, sondern durch die Morgenröte der Alternativen überstrahlt.
• Wer also etwas über den Wert von Technologien erfahren will, der darf nicht darauf warten, dass eine neutrale pro und contra abwägende Abhandlung veröffentlicht wird. Der (wahrgenommene) Wert einer Technologie ergibt sich aus ihrer An- und (!) Abwesenheit bei der Berichterstattung.
• Technologien haben einen Lebenszyklus. Der kann - wie CORBA zeigt - viele Jahre umfassen, selbst wenn die Technologie suboptimal ist. Ob eine Technologie wirklich ihrem Anspruch gerecht wird, ist dabei ebenfalls womöglich erst nach Jahren feststellbar. Wer also auf schnelle Orientierung durch die Berichterstattung hofft, hofft vergebens.

Daraus folgt: Ob eine Technologie etwas taugt, ist an der Berichterstattung über sie nicht wirklich ablesbar. Die informiert zunächst und vor allem über Neuigkeiten und das, was geht. Das muss dann jeder Einzelne als Anlass nehmen, die Technologien selbst einer Prüfung im Hinblick auf seine Problemszenarien zu unterziehen.

So ist es halt. Aber muss es so sein? Wahrscheinlich. Es gibt einfach derzeit keine Lobby für negative Berichterstattungen zu Technologien und Konzepten. Wer schreibt, will kaum über Misserfolge schreiben. Und wer veröffentlicht, der ist an attraktiven hoffnungstragenden Themen interessiert und nicht an Misserfolgen. Wenn schon die Veröffentlichung von falsifizierenden Forschungen in der qua Anspruch neutralen Wissenschaft ein Problem ist, dann allemal die von negativen Erfahrungen in Publikationen "nur" für ein Fachpublikum.

Wer Orientierung sucht, muss also selbst ständig beobachten und die Themenlebenszyklen im Blick behalten. Um das Selberlernen, das eigene Evaluieren führt wieder einmal kein Weg herum.

Oder? Wo ist die Publikation, die genau das aufgreift und Themenentwicklungen verfolgt? Das wäre doch mal etwas! Das wäre eine Dienstleistung ab vom Üblichen, die wirklich etwas bringen können. Die Branche würde sich selbst reflektieren. Ein Zeichen von Erwachsenwerden wäre das. Allerdings: Zu schön, um wahr zu werden, fürchte ich.

Lieber grün freuen als schwarz sehen - Zufriedener mit Unit Tests

Grad habe ich den Code für meinen nächsten dotnetpro-Artikel fertiggestellt. Zuerst wollte ich ihn einfach nur so runterprogrammieren. Zwar bin ich ein Freund solider Planung und automatischer Tests, aber ich hatte den Chor der Entwickler im Ohr, die da singen "Aber muss denn das immer sein?" So hatte ich mich entschieden, auf Contract-First Design zu verzichten, keinen DI-Framework einzusetzen und eigentlich auch keine großartigen Unit Tests anzulegen.

Aber: Selten so gelacht. Diese Vorsätze konnte ich keine Stunde einhalten. Echt. Ich konnte nicht. Ich musste eine Architektur zumindest auf 2-3 Blättern skizzieren und Kontrakte andeuten. Die Last, das alles nur im Kopf zu versuchen, war mir einfach zu groß: ich hätte mich dafür anstrengen müssen und ich wäre in Sackgassen bei der ad hoc Implementierung gelaufen, die mich Mehraufwand gekostet hätten.

Das hat mir schonmal gezeigt, dass Architektur eine Gewohnheitssache ist. Am Anfang kann man ohne, weil man sich ihres Wertes nicht so bewusst ist. Dann macht es Mühe, sich auf sie einzulassen. Es tut weh, seine Gewohnheiten zu ändern. Man muss sich schon dazu zwingen. Aber wenn man am Ende dieses Tals der Tränen herauskommt, dann ist der Prozess ganz natürlich. Dann kann man - oder zumindest ich - nicht mehr anders. Dann ist Architektur ein Muss. Sonst fehlt einfach etwas.

Um den Beispielcode aber nicht mit Details zu überfrachten, habe ich trotzdem die Kontrakte nicht in eigene Assemblies gesteckt und auch kein DI-Framework benutzt. Soviel dann doch als Zugeständnis an den Entwicklerchor ;-)

Dann das Testen. Eigentlich wollte ich nicht. Aber dann konnte ich doch nicht anders. Die Architektur einfach so zu implementieren und dann durch das kleine Frontend zu testen... nein, das ging nicht. Ich habe es echt versucht. Aber ich hab es dann nicht ausgehalten, so lange auf Feedback zu warten. Um herauszufinden, ob eine Infrastrukturfunktionalität des Beispielcodes funktioniert, hätte ich irgendwie künstlich einen Durchstich vom Frontend dorthin machen müssen. Wasfürein Aufwand! Oder ich hätte einfach weiter programmieren müssen, bis irgendwann man ein Durchstich da ist. Welch frustrierende Wartezeit!

Und so habe ich doch wieder alle Bereiche mit Unit Tests abgedeckt. Schritt für Schritt, eine Methode nach der anderen. Das hat sich einfach gut angefühl. Eine Erleichterung war es, nach ein wenig Programmierung mich beim Testen entspannen zu können.

Zweierlei ist mir dabei aufgefallen:

1. Proaktives Testen geschieht in einem positiven Gefühl. Ich bin ganz aufgeregt, wenn ich den Test schreibe, weil ich ja sehen möchte, ob meine Idee vom Code richtig ist. Wenn ich hingegen auf einen solchen sofortigen Test verzichte und darauf warte, dass irgendwann mal eine Nutzung durch das Frontend auf einen Fehler stößt, dann ist mein Gefühl negativ. Dann teste ich nicht proaktiv, sondern debugge, d.h. ich befinde mich in einem Problemmodus. Schlechte Laune garantiert.
2. Ein häufigerer Rollenwechsel zwischen Programmierer und Tester schafft Abstand zu Code. So entsteht Raum für Reflektionen. Das kann nur positiv sein, denn dann sehe ich plötzlich Dinge, die ich beim unausgesetzten Programmieren "im Flow" übersehen würde. Solcher Rollenwechsel entschleunigt auch in gewisser Weise. Auch das ist gut: für die Seele und den Code.

Also mal abgesehen von den Vorteilen automatischer Tests in punkto Refaktorisierbarkeit von Code habe ich für mich gemerkt, dass der Gewinn schon davor in einem guten Gefühl, in Entspannung liegt. Positive Einstellung und Entschleunigung machen einfach Spaß. Ich habe mich sozusagen grün gefreut angesichts der wachsenden Zahl kleiner grüner, also positiver Rückmeldungen vom Unit Testing Framework in ReSharper 4.0 (s. Bild oben).

So richtig zufrieden haben mich die grünen Rückmeldungen aber erst werden lassen, als ich zusätzlich noch auf die Codeabdeckung der Tests geachtet habe. Fehlerfreiheit lässt sich ja nicht nachweisen. Also sagt ein grüner Test nicht, dass Code ohne Fehler ist. Tests überprüfen nur Erwartungen. Um ein gutes Gefühl zum Code zu bekommen, muss ich mehr als eine Erwartung haben; jeder Teil des Codes - jede Verzweigung, jede Methode - sollte meine Erwartungen erfüllen. Also müssen meine Tests möglichst viel Code abdecken. Meine Wunschmarke ist 90% Codeabdeckung. 100% sind natürlich noch besser - wenn auch nicht immer ausreichend -, aber ab und an lasse ich mal den Code für einen exotischen Fehlerfall ungetestet.

Mit der Integration von TestDriven und NCover habe mein gutes, grünes Gefühl dann gefestigt. Wie das nebenstehende Bild zeigt, decken meine Tests 97% der Codebasis ab. Das finde ich für den Zweck des Beispielcodes ausreichend.

Und so habe ich mich denn wirklich gut gefühlt, ganz grün vor Spaß, statt vor lauter Bugs schwarz geärgert. Architektur und Testen sind Gewohnheiten. Wenn man sie sich zum Nutzen der Codequalität einmal angeeignet hat, dann ist´s schwer, sie wieder abzustreifen. Aber es sind ja keine schlechten Gewohnheiten. Und sie haben mir ein gutes Gefühl verschafft. Was will ich mehr?