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.
- 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.
- 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.
Im 
Wie stehts nun aber mit den "Beratungs- und Requirements Engineering-Fähigkeiten"? So sehr ich auch für einen Aufbau von Softskills bei Softwareentwicklern bin (s. dazu auch meinen Beitrag 
Das hat Spaß gemacht! Runden drehen auf der 
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?