Rein in die Matrix!

Sind Event-Based Components (EBC) ne super Sache oder “krank” (wie gerade in einem Diskussionsforum behauptet wurde)? Tja… ich glaube natürlich, dass sie ziemlich cool sind und was bringen. Der Entwurf von Software wird damit einfacher, die Wartbarkeit, äh, Evolvierbarkeit steigt, die Verständlichkeit ebenfalls und automatisierte Tests brauchen keine Mock-Frameworks mehr.

Es gibt auch eine kleine Community um EBC, die dasselbe denkt. Die Majorität der Entwickler ist jedoch – wenn sie denn EBC überhaupt kennen – mindestens indifferent. Ist es deshalb aber besser, weiterzumachen wie bisher? Oder wären EBC ein Gewinn für sie? Wer hat nun recht? Und in welchen Fällen?

Ich glaube, da können wir Überzeugte uns noch lang den Mund fusselig reden und schreiben, am Ende zählt immer nur eine Gegenüberstellung. Wer die aber nicht kundig selbst macht oder machen kann, der wird nicht überzeugt. Also muss die Gegenüberstellung anders laufen. Sie muss präsentiert werden.

Deshalb möchte ich ein Angebot machen:

Wer glaubt, EBC brächten nichts oder würden irgendwie die Softwareentwicklung sogar noch behindern, der kann sich mit seinem Ansatz zur Planung von Software im fairen, harten aber herzlichen Wettstreit mit mir messen. Wie wäre das?

Das ist dann natürlich kein wissenschaftliches Experiment. Dennoch ließe sich was lernen. Auf beiden Seiten. Da bin ich mir sicher.

Ich schlage vor, dass ein solcher “Shoot Out” in einer .NET User Group stattfindet. Sicher gibt es eine, die den Event hosten würde. Diese User Group würde beiden Parteien – EBC und Non-EBC – eine Aufgabe stellen, die die dann in einer Timebox umsetzen müssen. Zeitaufwand ca. 3 Stunden von der Anforderungspräsentation bis zur Auslieferung.

Am Ende würde mit vorgefertigten automatisierten Akzeptanztests geprüft, inwieweit die Anforderungen erfüllt sind. Zwischendurch – vielleicht nach 1,5 bis 2 Stunden – würden noch neue Anforderungen nachgereicht. Und natürlich würde jede Partei ihre Lösung in einem Review vorstellen.

Die Akzeptanztests machen eine Aussage über die Korrektheit des Codes, den ein Ansatz produziert. Die Erfüllung auch der nachgereichte Aufgabe machen eine Aussage über die Fähigkeit, den Code zu verändern, d.h. die Evolvierbarkeit.

Die Größe der Aufgabe ist fast egal, würde ich sagen. Sie muss nicht mal komplett zu schaffen sein. Es reicht, wenn die Zahl der Akzeptanztests nicht zu klein ist und in der Timebox davon eine ganze Reihe schaffbar sind. Dann ließen sich sich Unterschiede im Erfüllungsgrad ablesen. Die nachgereichte Anforderung wäre allerdings eine Pflichtanforderung, die zumindest angegangen werden muss.

Was der Ansatz der anderen Partei ist, ist egal. Sie sollte nur mit C# programmieren. Ob dann streng OOP oder Cowboy Programmierung oder Komponentenorientierung oder Funktionale Programmierung oder sonstwas gemacht wird… alles ist recht.

Hm… einen Aspekt würde ich allerdings noch gern reinbringen: Entwicklung im Team. Wäre also vielleicht gut, wenn auf jeder Seite 3 Leute stünden. Das ist etwas realitätsnäher und ließe größere Aufgaben zu.

Wäre das nicht mal ein Coding Dojo der besonderen Art? Ein “Shoot Out” Dojo oder Contest Dojo.  EBC gegen den Rest der Welt :-)

Wer nimmt die Herausforderung an?