Follow my new blog

Donnerstag, 28. August 2008

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?

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

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

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

8 Kommentare:

Anonym hat gesagt…

Es geht nicht immer nur um's sparen.
Ein Frage die man sich auch Stellen kann: "Was für neue Möglichkeiten ergeben sich durch den Einsatz einer neuen Technologie?". WPF ist hier ein gutes Beispiel.

Ralf Westphal - One Man Think Tank hat gesagt…

@Bonk: Natürlich geht es nicht "immer" (also in 100% aller Fälle) ums Sparen. Aber es geht meistens, allermeistens ums Sparen.

"Enabling technologies", d.h. Technologien, die etwas ermöglichen, was vorher eher nicht möglich war, sind selten. WPF ist da die Ausnahme.

Der Grund dafür, dass es meistens ums Sparen geht ist ganz simple: Innovationen verstehen und kreativ einsetzen ist ein aufwändiger Prozess, der Spielräume braucht. Solche Spielräume haben die meisten Projekte einfach nicht.

Da mag man noch soviel reden, dass das Wichtigste Innovationen sind. Am Ende setzen die meisten Projekte auf kleine Verbesserungen des Bewährten, konservatives Vorgehen, Benchmarking. Erst wenn ein anderer innoviert, rücken sie nach - innovieren dann aber nicht mehr selbst.

-Ralf

Anonym hat gesagt…

Hallo Ralf,

ich befürchte dass diese Strategie die langfristigen Auswirkungen zu wenig berücksichtigt. Ob es günstig ist auf 'x' zu setzen kann ich erst entscheiden wenn 'x' auch bewiesen hat dass es langfristig 20% besser ist. Es gibt Beispiele bei denen ich anfangs 20% gewinne, später aber drauf zahle wenn das Projekt wächst und älter wird.

Für mich persönlich stehen die Prinzipien der Softwaretechnik im Vordergrund (womit ich nicht ausschließe auch deine 80:20 Regel anzuwenden). So muss jedes neue 'x' z.B. das Single Responsibility Principle unterstützen. Würde der Einsatz von 'x' dazu führen dass meine Business Objects plötzlich Infrastrukturanteile enthalten wäre ich skeptisch. Als nächstes kommt das Open Close Principle. Ist 'x' offen für Erweiterungen ohne dass 'x' selbst modifiziert werden muss? Diese (und weitere) Kriterien ermöglichen mir die Entscheidung ob ich mich mit einem neuen 'x' (oder auch einem neuen X#) befasse oder es (erstmal) nicht weiter verfolge.

Herzliche Grüße,
Stefan Lieser

Ralf Westphal - One Man Think Tank hat gesagt…

@Stefan: Es ist sicherlich gut, dass du ein Auge auf solche Prinzipien hast.

Aber so recht verstehe ich nicht, wie F# oder EF oder SharePoint oder eine Complex Event Processing Engine oder WF usw. damit etwas zu tun haben könnten.

Wenn du auf F# umsteigen würdest (so wie du mal auf C# umgestiegen bist), dann würde sich das auf deinen ganzen Code sehr tiefgreifend auswirken. Wäre das deshalb schlecht? Nein.

Wenn du WF statt selbstgebastelter Workflows einsetzen würdest, dann könntest du selbstverständlich das Single Responsibility Principle selbst weiterhin einhalten - oder nicht. Wie du möchtest. Das hat nichts mit der Technologie zu tun.

Und natürlich hast du Recht, dass die Zeit im Blick zu halten ist. Aber irgendwann muss man eine Entscheidung treffen. Zu dem Zeitpunkt ist man immer und notwendig "dümmer" als hinterher. Außerdem verändert die Entscheidung für eine neue Technologie das Gesamtsystem. Wie, das kannst du nicht immer vorhersehen. Insofern: Der Versuch, über einen bestimmten Zeitraum Effekte abschätzen zu wollen, ist oft recht müßig. Deshalb: auf die Beschreibung des Neuen jetzt blicken, jetzt beurteilen, ob nach einer Anlaufphase die 20% Besserung drin sind. Die Verantwortung solcher Beurteilung durch dich, kann du nicht entgehen. Wer sie versucht auf die Community abzuschieben, der wird wieder zum Vogel Strauß.

Deshalb sehe ich die Anbieter in der Pflicht, sich mehr Mühe zu geben, die 80:20-Fragen möglichst früh zu beantworten.

-Ralf

Anonym hat gesagt…

Hallo Ralf,

zu F# würde ich ja nicht umsteigen wie zu C# sondern ich würde Teile, die in einer funktionalen Sprache besser auszudrücken sind in F# machen, den Rest weiterhin in C#.

Anyway... bei der Beurteilung einer Technologie muss ich berücksichtigen welche Auswirkungen die Technologie auf meine Codebasis hat. Zwingt mich eine Technologie dazu Prinzipien zu verletzen ist das ein starkes Argument gegen die Technologie.

Wenn z.B. das Entity Framework 20% "Verbesserung" verspricht muss ich dazu bereit sein das Prinzip der Infrastruktur Ignoranz zu lockern. Das alleine könnte schon das ausschlaggebende Argument gegen den Einsatz des EF sein.

Wenn ich mit SharePoint (wovon ich keine Ahnung habe) nicht test-first arbeiten kann müssen schon viele gute Argumente kommen um das Prinzip zu verletzen.

Wenn die WF mich zwingen sollte die Workflows so zu implementieren dass ich mehrere Aspekte zusammenwerfen muss (sprich das SRP verletze) wäre auch das ein Gegenargument.

Ich stimme dir voll zu, dass ich die Entscheidung am Ende selber fällen muss. Mit Hilfe der Community kann ich meine Argumentation prüfen. Das bringt sicher Vorteile gegenüber einer Entscheidung im stillen Kämmerlein.

Herzliche Grüße,
Stefan Lieser

Ralf Westphal - One Man Think Tank hat gesagt…

@Stefan: Natürlich muss man die Auswirkungen berücksichtigen. Das steckt ja in der Vorderung von "20% Verbesserung" drin.

Da Prinzipien aber auch nur Werte wie andere sind, gilt es dabei (wie auch sonst im Leben) die bewussten Werte gegeneinander abzuwägen. Von einer pauschalen Ablehnung von Neuem, dass einen Wert kompromittiert, halte ich deshalb nichts. Das wäre nämlich deutsche Prinzipienreiterei und führt ebenfalls in die Starre.

Lebendige Softwareentwicklung kennt 1. ihre Werte und hat 2. Spielräume, die Werte immer wieder angemessen zu verschieben. Je mehr Werte berücksichtig werden können, desto besser. Aber immer alle 100% zu bedienen ist realitätsfern.

Wie nun aber jeder Einzelne seine Werte priorisiert, dass muss er für sich bestimmen. Es hängt womöglich auch vom Projekt ab oder von einer Projektphase.

Analogie: Einer meiner Werte ist "Ordnung im Kinderzimmer". Die Erfüllung dieses Wertes mit meiner 8jährigen Tochter jedoch ständig auf 100% zu halten, ist nicht nur illusorisch, sondern schlicht unnötig. Ihr Zimmer muss also nicht ständig ordentlich sein, sondern nur verlässlich immer wieder. Und es gibt sogar Bereiche, die müssen nie in Ordnung sein.

Und so sehe ich es durchaus auch für Werte in Bezug auf die Softwareentwicklung. Beobachten, abwägen, neu be-wert-en. So dass das Große Ganze immer besser wird und nicht nur ein Teil optimal bleibt.

-Ralf

Anonym hat gesagt…

In meinen Augen trifft es die Analogie mit dem Kinderzimmer am besten.

100% sind nie zu erreichen - und eine kleine Ecke mit Unordnung kann durchaus kreatives Potential fördern ;-)

Anonym hat gesagt…

Hallo Ralf,

ich kann deine Beobachtung und deine Schlussfolgerung aus meiner Erfahrung nur bestätigen.

Genaugenommen gibt es recht selten die echte "Innovationen" darstellen. 95% aller Produkte, Ideen, Prozesse, etc. sind tatsächlich nur Veränderungen mit dem Versprechen auch eine Verbesserung zu sein. Oftmals sind sie das nur partiell oder fallen in die 20% der Projekte, die man *nicht* macht.

Wenn mir Produkt X ein Quantensprung in Sachen Lazy Loading verspricht (was vielleicht sogar auch eingehalten wird), dann wird mit garantiert eine Schwäche bei Feature Y verschwiegen.

Ich habe recht selten Produkte oder Technologien gesehen, die mich vorbehaltlos begeistert haben. Um mit deinen Worten zu sprechen: Ich wußte sofort dass deine 80:20-Regel erfüllt ist. Oftmals sind es nicht die großen Entwürfe, die mich in meiner Arbeit nach vorne bringen, sondern kleine Tools, die mir meine Arbeit spürbar erleichtern.