Diskussions-Aikido – Diskussionen sind wie Kampfkunst...

Diskussionen gewinnen? Oder das Ziel erreichen?

Als guter und geübter Rhetoriker mag man in der Lage sein, viele Diskussionen nominell für sich zu entscheiden. Wenn der „Gegner“, der am Ende der Diskussion grollend klein beigibt aber gerade der Mensch ist, mit dem ich im Sinne der Sache zusammen arbeiten will – oder eventuell sogar „muss“ –, dann habe ich möglicherweise den Kampf gewonnen, aber das gesamte Vorhaben hat einen Verlust erlitten.

Der Klügere gibt so lange nach,…

… bis er der Dumme ist, heißt es von Zeit zu Zeit. Alleine der harmoniesuchende Kurs führt auch nur in wenigen Fällen zum Ziel.

Friedliche Kampfkunst als Muster?

Vor einer ähnlichen Situation stand der Entwickler des Aikido, als er diese Kampfkunst aus den sehr viel brutaleren Kampfkünsten die er vorher unterrichtet hatte entwickelte.
Er entwickelte eine Kampfkunst, die die Energie des Angreifers nicht nur gegen ihn selbst wendet, sondern die angreifende Partei so behutsam abwehrt, dass hinterher ein friedliches Miteinander realistisch bleibt.

Aikido in der Diskussion

Wie sich Aikido und Rhetorik nach unserer Sicht miteinander verbinden lassen haben Björn Klug und ich auf der OOP2015 in einem Vortrag zusammengefasst...

Diskussionen sind wie Kampfkunst

Der Vortrag.

Bis bald …
  Michael Mahlberg

Die Angst des Software-Entwicklers vor der Kommandozeile... ?

Haben Software-Entwickler denn Angst vor der Kommandozeile?

„Angst“ ist natürlich ein starkes Wort, aber es fällt mir schwer eine andere Interpretation für das Verhalten zu finden, wenn Entwickler für die Versionsverwaltung lieber Subversion als git verwendeten, weil es für git keine gut funktionierende Explorer-Integration (wie z. B. TortoiseSVN) gab¹ und sie deshalb mit der Kommandozeile arbeiten müssten. Oder, dass eher Excel eingesetzt wird als SQLite um Tabellen auszuwerten, weil man für SQLite ja „immer die Kommandozeile braucht“. Oder, dass zwar die IDE-Funktion zum Erzeugen des auslieferbaren Produktes genutzt wird, aber nicht der Aufruf von make, rake, ant, maven, gradle etc. von der Kommandozeile.

Die Beispiele ließen sich lange weiterführen, aber die grundlegende Frage bleibt: Warum schrecken so viele Entwickler vor der Nutzung der Kommandozeile zurück?

Ist das Werkzeug des Software-Entwicklers nicht „Text“?

Tagein, tagaus schreiben Software-Entwickler Programmcode¹. Zwar bei weitem nicht so viel, wie viele Nicht-Programmierer denken – nach verschiedenen Studien liegt das Verhältnis von Lesen zu Schreiben bei 7 zu 1 oder noch höher –, aber dennoch gehört das Schreiben von Worten in einer Sprache, die ein Programm interpretieren und bearbeiten kann, zum Alltag eines jeden Softwareentwicklers. Und nicht nur das, die meisten Entwickler beherrschen darüber hinaus noch eine ganze Reihe von solchen Sprachen, die sie benötigen um ihr Tagewerk zu vollbringen.

Woher also kommt der Widerstand gegenüber der Kommandozeile? Ist es die schlechte Benutzbarkeit der jeweiligen Kommandozeilen der Betriebssysteme? Die schlechte Dokumentation? Die Tatsache, dass die jeweilige Domäne schon komplex genug ist, und die Vereinfachung durch eine grafische Oberfläche dringend benötigt wird?

Ich habe leider wirklich keine Antwort und würde mich über Hinweise auf Erklärungsansätze – z. B. in den Kommentaren, aber auch gerne per Mail oder Twitter freuen.

Bis demnächst
  Michael Mahlberg

---

Fußnote

¹ Ob es gut ist, dass es mittlerweile mit TortoiseGit ein Tool gibt, dass es ermöglicht, mit git nahezu genau so zu arbeiten, wie früher mit Subversion ist eine andere Frage

Quasi-Fußnote

² Strenggenommmen manipulieren Softwareentwickler abstrakte Syntax-Bäume (AST), indem sie deren textuelle Repräsentation gestalten. Die heute noch übliche Weise, die textuellen Repräsentationen zu manipulieren, ist das Erfassen des Textes über die üblichen Methoden der Texteingabe (Tastatur, Sprache etc.). Hierbei wird die textuelle Darstellung jedes mal neu erzeugt, wobei heute kontext-erkennende Entwicklungsumgebungen bereits viele Vorschläge für die Vervollständigung der einzelnen Worte machen. Bereits 2003 allerdings stellte James Gosling eine Alternative zu dieser Herangehensweise vor: Eine Entwicklungsumgebung, die direkt den AST manipuliert und die textuelle Repräsentation nur noch für den menschlichen Benutzer generiert. Leider war „Jackpot“, so der Name dieses Projekts, kein großer Erfolg beschieden und heutzutage ist es schwer überhaupt noch Information über dieses Projekt zu finden.

Ein anderes System, das erfolgreich viele Jahre auf Texteingaben zur Softwareentwicklung – außer für Werte – verzichtete, war das von James Martin Associates (später von Texas Instruments gekauft) entwickelte Information Enginering Facility (IEF), aus dem heute das Tool CA Gen geworden ist, welches sich mittlerweise ebenfalls vom Gedanken der reinen Modellierung der Syntaxbäume entfernt hat.

Insgesamt scheint also die unsichtbare Hand des Marktes doch ein großes Interesse daran zu haben, dass Entwickler weiterhin in aktiv Text schreiben um Programme zu erstellen und maximal durch Werkzeuge wie die automatische Vervollständigung von Schlüsselworten unterstützt werden.

Unpopuläre Thesen 2013-09-25: Scrum und Kanban sorgen nicht für gute Softwareentwicklung

Scrum an sich macht niemanden zu einem besseren Software-Entwickler!
Und (Software-)Kanban macht als solches ebenfalls niemanden zu einem besseren Software-Entwickler (und ist – nebenbei bemerkt – auch kein Ersatz für Scrum! )

Und – nur um es noch mal deutlich zu machen – Scrum ist kein Synonym für "Agil" oder "Agile". Unter den Agilen Methoden sorgt zum Beispiel eXtreme Programming (XP) meiner Ansicht nach sehr wohl für gute Softwareentwicklung, solange man es ausreichend ernst nimmt.
Aber zurück zu Scrum. Das Schöne an Scrum ist ja gerade, dass es so universell einsetzbar ist! Um die deutsche Übersetzung des Scrum-Guide zu zitieren: „Scrum ist ein Framework, das die Entwicklung komplexer Produkte unterstützt.“ In diesem Satz steht nichts von Software – und wenn man den Scrum-Guide nach „Programm“ oder „Software“ durchsucht, wird man ebenfalls nicht fündig – egal, ob in der englischen Ausgabe vom Juli 2013 oder in der deutschen Übersetzung zum Stand 2011.

Eines der bekannteren Beispiele für die Anwendung von Scrum ausserhalb der Software-Entwicklung ist die Wartung von Formel-1 Wagen mit Scrum^[1] – ich bin sicher, dass gerade hier von allen Team-Mitgliedern erwartet wird, dass sie ihr Handwerkszeug perfekt beherrschen.

Die Dinge, die dabei helfen, bessere Software-Entwickler zu werden, sind andere: Wissen über Entwurfsmuster (siehe auch: Wikipedia), Kenntnis von Architektur und Entwurfsprinzipien (z. B. SOLID (siehe auch: Wikipedia) und Co.), Einsatz von testgetriebenem Design, Programmieren in Paaren, kontinuierliche Integration und letztendlich – auch wenn aus einem gewissen Blickwinkel die konkrete Programmiersprache nicht so entscheidend sein mag – die Beherrschung der für die Umsetzung notwendigen Sprachen, Bibliotheken und Frameworks.
Wenn diese Elemente erfüllt sind, dann helfen Prozesse wie Scrum und Prozessverbesserungsmethoden wie die Kanban Methode (oder als englische Kurzübersicht) dabei, wirklich das zu entwickeln, was einen Wert für den Kunden darstellt, und sich nicht in Technikalitäten zu verlaufen, in der Analyse stecken zu bleiben oder in eine der vielen anderen Fallen des Projektmanagements zu laufen.
Analog zum alten Rezept für einen guten Grog („Rum muss, Zucker kann, Wasser braucht nicht“) an dieser Stelle daher mein Plädoyer:

• Technische Expertise: Notwendig, aber nicht hinreichend
• Kanban Methode: Sollte, aber nicht als einziges
• Scrum: Kann, aber nicht als einziges

Bis demnächst
  Michael Mahlberg

---

[1] Die „Scrum in der Formel-1“ Geschichte hält sich seit Jahren, ich habe aber leider keine Primärquellen finden können

Polyglotte Programmierung ist Alltag

Von Zeit zu Zeit wird die Idee, das man deutlich mehr als eine Programmiersprache beherrschen sollte unter der Bezeichnung "Polyglotte Programmierung" – also "vielsprachige Programmierung" – als progressive Erkenntnis oder auch als Wettbewerbsvorteil proklamiert. Mich verblüfft das immer wieder – ebenso wie die ablehnenden Reaktionen einiger Entwickler zu dieser Idee.
Schließlich leben wir schon lange in einer Welt, in der es für Entwickler unverzichtbar und meines Erachtens auch Alltag ist, mehr als eine Sprache zu benutzen.

In den meisten Fällen, die über triviale "Hallo, Welt!" Beispiele hinaus gehen, kommen heute fast immer mehre Sprachen (seien es Programmier- oder Beschreibungssprachen) zum Einsatz. Gucken wir uns nur mal einige wenige Beispiele an:

• .Net, Desktop-Anwendung

  • C# (oder VB.Net oder eine andere Sprache der Wahl) für die Logik
  • SQL für die verwalteten Daten

• PHP, Web-Anwendung

  • PHP - für die Implementierung der Logik,
  • HTML - für die logische Gestaltung der Benutzungsschnittstelle
  • CSS - für die optische Gestaltung der Benutzungsschnittstelle
  • SQL - für die verwalteten Daten
  • Wahlweise: Shell-Syntax - mindestens zum starten und stoppen des Servers, kopieren von Dateien etc. (kann ggf. auch mit einem grafischen Interface gemacht werden)
    • Wenn es etwas mehr sein darf
    • Java-Script - für Interaktionen im Oberflächenlayer
    • die jeweilige Sprache (oft XML-basiert) für die Konfiguration des Build-Servers
    • Config-Sprache des Servers (e.g. apache-conf)

• Ruby, Web-Anwendung, Stack von ~2012

  • Ruby - für die Logik
  • haml - für die logische Gestaltung der Oberfläche
  • Sass - für die optische Gestaltung der Oberfläche
  • Coffeescript - für die 'clientseitige' Logik
  • yaml - für diverse Einstellungen, nicht zuletzt die Unterscheidung zwischen Test- und Realbetrieb
  • RSpec / Cucumber - für die lokalen Tests
  • Capybara DSL - für remote Tests
  • SQL - für die verwalteten Daten

• Java, Web-Anwendung, Minimalistisch

  • Java - für die Logik
  • HTML - für die logische Gestaltung der Benutzungsschnittstelle
  • CSS - für die optische Gestaltung der Benutzungsschnittstelle
  • JSP-taglibs - für die dynamischen Teile der Oberfläche
  • SQL - für die verwalteten Daten
  • XML - für die Buildskripte
  • Property-File Syntax -
  • Wenn es etwas mehr sein darf
    • Java-Script für Interaktionen im Oberflächenlayer
    • die jeweilige Sprache (oft XML-basiert) für die Konfiguration des Build-Servers
    • Config-Sprache des Servers (e.g. apache-conf)

Und ähnlich sieht es bei allen weiteren mir bekannten Umgebungen aus, wenn wir von professioneller Softwareentwicklung (Nein, Excel-Markos zähle ich nur selten dazu, manchmal aber schon) sprechen.

Also sollte die Frage heute weniger denn je lauten "Was ist denn unsere Standardsprache" sondern viel mehr "Welche Sprache passt am besten zum Problem".

Bis demnächst
  Michael Mahlberg

Es gibt keine Server für kontinuierliche Integration (oder auch "CI-Server" ist ein Oxymoron)

Sätze wie

• „Der gesamte Vorgang wird automatisch ausgelöst durch Einchecken in die Versionsverwaltung.“[1]
• „<x> is an open-source continuous integration server with...“ [2]
• „[…] Kontinuierliche Integration steigert die Effizienz durch Automatisierung […]“[3]

zeigen mir immer wieder die immense Macht der semantischen Diffusion.

Es gibt keine CI-Server – selbst Szenarien, in denen der Server am Ende eines fehlerhaften Buildlaufes das gelieferte Changeset zurückweist, stellen nicht sicher, dass die Teilergebnisse wirklich integriert werden.

Was oft als CI-Server beschrieben wird, sind Build-Server, integriert wird hier nichts. Buildserver gibt es durchaus auch in meinem Vokabular, kontinuierliche Integration aber, so wie ich sie das erste Mal 2001 bei Kent Beck beschrieben gesehen habe, ist eine Arbeitsweise, bei der alle Beteiligten sicherstellen, dass ihre letzten fertiggestellten Arbeitsergebnisse in das Gesamtprodukt integriert sind. Dorthin zu kommen, gibt es viele Wege, aber keiner davon ist durch einen Server zu automatisieren.

Auf abstraktem Niveau ist das Vorgehen immer wieder das Gleiche:

• An den eigenen Arbeitsergebnissen arbeiten
  • Sicherstellen, dass die aktuelle Version des Produktes funktioniert
  • Meine eigenen Arbeitsergebnisse integrieren
  • Sicherstellen, dass die jetzt aktuelle Version des Produktes funktioniert
  • wenn sie nicht funktioniert, wieder einen funktionierenden Stand herstellen
    • Wenn dies ebenfalls nicht funktioniert, dann das ganze Team zusammenrufen, um wieder einen funktionierenden Stand herzustellen
  • Die eigenen Arbeitsergebnisse modifizieren, bis berechtigter Grund zu der Annahme besteht, dass eine Integration jetzt erfolgreich sein kann
• Das Ganze so lange wiederholen, bis die eigenen Arbeitsergebnisse komplett in das Gesamtprodukt integriert sind, bevor neue Halbfertigteile produziert werden

In der Praxis gibt es sehr viele valide Ausprägungen dieses Vorgehens, die unter anderem auch die Nutzung von Buildservern umfassen können. Sie alle aber scheinen zunächst einen erheblichen Nachteil zu haben, der meiner Meinung nach Ursache dafür ist, dass so oft keine permanente Integration stattfindet, sondern statt dessen das fehlen der Integrationsarbeit hinter dem Feigenblatt des „Integrations-Servers“ versteckt wird.
Dieser Nachteil ist, dass in dieser Welt nicht mehrere „Änderungen“ zur gleichen Zeit integriert werden können. Und da die Integration nach diesem Modell ja erst abgeschlossen ist, wenn das System nachweislich funktioniert, steht und fällt die Umsetzbarkeit dieses Vorgehens mit der Zeit, die benötigt wird, um das Funktionieren des Gesamtsystems nachzuweisen.

An dieser Stelle sind zwei grundsätzlich unterschiedliche Herangehensweisen üblich. Eine Lösung für die Herausforderung kann sein, die Zeit zu minimieren, die benötigt wird, um das Funktionieren des Gesamtsystems nachzuweisen. Das ist der „harte” Weg, der zunächst deutlich schwieriger scheint und es erforderlich macht, sich mit allen Problemen auseinanderzusetzen, sobald sie auftauchen. Eine andere – scheinbare – Lösung, dieser Herausforderung zu begegnen, ist die Entkopplung der Integration von der Weiterführung der Arbeiten. Hier haben dann automatisierte Integrationstests und die sogenannten „CI-Server” ihren großen Auftritt.

Das Vorgehen hier ist also:

• An den eigenen Arbeitsergebnissen arbeiten
• Die eigenen Arbeitsergebnisse zur Verifikation an den Integrationsserver abgeben (möglicherweise von mehreren Teams zur Zeit)
• An neuen eigenen Arbeitsergebnissen arbeiten
  hier haben wir je nach Anzahl der Entwickler mehr oder weniger nicht-integrierten Code
• Falls (später) ein Fehler vom Server gemeldet wird, versuchen diesen zu beseitigen

Das ist natürlich viel einfacher, es gibt keine Schleifen, die man drehen muss, keine Synchronisation mit anderen Integrationswilligen, keine Wartezeiten während der Integration.

Das große Problem bei diesem Vorgehen ist nur, dass nicht verifizierte Teilfertigprodukte entstehen – um so mehr, je häufiger die Entwickler ihre Teilergebnisse an den Server überantworten.

Es gibt zwar schon geraume Zeit Ansätze dieses Thema auch technisch zu adressieren – z. B. mit gerrit und darauf aufsetzenden Workflows – aber hier dienen die Werkzeuge erfreulicherweise der Unterstützung der Menschen, und es wird nicht unterstellt, dass sie die Integration durchführen.

Eigentlich lässt sich ganz leicht feststellen, ob es in einer Umgebung eine permanente Integration gibt oder nicht – immer dann, wenn es fehlerhafte Builds gibt, scheint die Integration weder permanent noch kontinuierlich zu sein.
Schließlich ist in der „roten“ Zeit mindestens der für den Fehler verantwortliche Teil eben gerade nicht integriert. Und wenn die Build-Zeit lang genug ist, dann ist in der Zeit Neues entstanden, was ebenfalls nicht integriert ist. Und während die Fehler behoben werden steigt die Menge nicht integrierter Teilprodukte, wenn die anderen Projektmitglieder weiter arbeiten.
All dies passiert nicht, wenn tatsächlich nach dem oben beschriebenen Muster permanent integriert wird!

Wer also permanente Integration (continuous integration) will, muss sich meiner Ansicht nach auf Prozessebene damit auseinandersetzen und wir alle sollte Build-Server auch Build-Server nennen und den Begriff CI-Server meiden, solange diese keine wirkliche Integration betreiben können.

Bis zum nächsten Mal
  Michael Mahlberg

Quellen aus der Einleitung:

• [1] aus dem deutschen Wikipedia Eintrag
• [2] von der Jenkins Startseite
• [3] aus einem Industrieartikel

Und gerade noch im Netz gefunden: Bereits vor 2006 hat Jim Shore seine Einstellung zu Continuous Integration veröffentlich, und hatte insbesondere seine eigene Meinung zu CruiseControl (einem speziellen Build-Server)

Unpopuläre Thesen 2013-09-03: "Agil" sollte beweglich bleiben – und Lean sollte schlank bleiben

Agile Software-Entwicklung hätte fast den Namen Adaptive Software-Entwicklung bekommen - vielleicht wäre dann vieles gar nicht erst so Missverstanden worden. Vielleicht aber auch doch - semantische Diffusion ist stark in unserer Branche.

Sehr schön in diesem Zusammenhang: Die Rückbesinnung einiger Twitterer auf ein paar wesentliche Punkte des agilen Manifests:

sie haben gesagt "[…] indem wir es tun und anderen dabei helfen es zu tun […]" und nicht "[…] indem wir anderen erzählen, wie sie es tun sollten, ohne es selbst zu tun […]" -- Tweet von Torbjörn Gyllebring, 2013-08-29

Zur Erinnerung: sie sagten "Wir erschließen bessere Wege, Software zu entwickeln" und nicht "wir haben bessere Wege erschlossen[…]" -- Tweet von Steve Rogalsky, 2013-08-29

In diesem Sinne, bis bald
  _MM_

Wir haben Baseball ausprobiert und es hat nicht funktioniert!

Eine Allegorie? Sarkasmus? Humorvolle Persiflage? Entscheiden sie selbst.

Von Ron Jeffries, Original unter: http://xprogramming.com/articles/jatbaseball/

Die fanatischen Fürsprecher des Baseballs erzählen uns, es sei ein unglaublich tolles Spiel, das sowohl den Spielern als auch den Zuschauern viel Spaß macht. Es ist ganz klar zu erkennen, dass die Fürsprecher entweder dumm oder böse sind, denn wir haben Baseball ausprobiert und es hat nicht funktioniert.

Es fängt schon damit an, dass die Anforderungen um das Spiel zu spielen unsinnig sind - sie lassen sich einfach nicht skalieren. Es werden mindestens neun Spieler pro Seite verlangt. Das ist unglaublich ineffizient. Die Minimalanzahl an Spielern ist ganz klar vier: drei im Spiel und einer am Abschlag. So haben wir auch gespielt vier Spieler pro Seite.

Mit nur vier Spielern brauchten wir auch nicht all diese Male (die Namensgebenden 'bases'), was ein weiteres Indiz für die offensichtliche Ineffizienz und die mangelnde Skalierbarkeit ist. Wir haben deshalb nur ein einziges Mal benutz - die 'Home-Base'. Wenn eine schlagende Person einen Ball schlägt, dann läuft er um ein Quadrat - mehr dazu gleich - um dann zurück zum einzigen Mal zu kommen. Zuerst ließen wir den Läufer um das komplette 90 Fuß (ca. 27 Meter) Quadrat laufen, wie es die Baseball-Befürworter empfehlen. Aber aus irgendeinem Grund haben die Baseballleute nicht bemerkt, dass 360 Fuß (ca. 110 Meter) bei den meisten Treffen viel zu weit ist, um sie rechtzeitig zurück zu legen. Bei uns hat es nie jemand geschafft, die ganze Strecke zu laufen ohne aus dem Spiel genommen zu werden. Wir haben festgestellt, dass ein Kreis mit einem Durchmesser von exakt 28,64 Fuß (8,73 Meter) nahezu ideal ist. (Der Kreis, mit seinem idealen Verhältnis von von Fläche zu Umfang, ist auch viel effizienter als das von den Baseballern vorgeschlagene Quadrat.)

Die Ausrüstung, die die Baseball-Leute "verlangen" ist einfach lächerlich, anachronistisch, diskriminierend und gemein. Als erstes wird verlangt, das der "Baseball" mit Pferdeleder bedeckt ist.Das ist gleichzeitig brutal gegenüber den Pferden und diskriminierend gegenüber den traditionellen Lieferanten von Ball-Aussenmaterial, Schweinen und Kühen. Vor diesem Hintergrund haben wir andere Bälle benutzt. Wir haben einen Ball aus un-umhülltem Garn ausprobiert, aber die permanent abnehmend Größe dieser Bälle mache das Spiel schwierig, besonders in den späteren Runden. Golfbälle flogen viel zu weit und waren schwer zu fangen. Eines unserer Teams versuchte es mit den Köpfen von Puppen, die sie von Ihren Schwestern geborgt hatten, aber das führte zu Problemen zuhause. Wie die Befürworter von Baseball ein Spiel unterstützen können, das zu solchen Problemen führt ist uns unverständlich.

Am Ende haben wir uns für Wollsocken entschieden - mit Altpapier gestopft und verknotet. Diese waren einfach zu fangen, flogen nicht zu weit und das herabhängende Ende des Knotens machte es leicht, sie wieder zu werfen.

Die sogenannten "Bats" (Bat kann im Englischen sowohl Fledermaus als auch Schläger bedeuten) sind auch eine schlechte Idee. Zuerst mal haben sie überhaupt keine Ähnlichkeit mit den pelzigen Insektenjägern der Nachthimmel. Die daraus entstandene Verwirrung über die Namensgebung hat viele Spiele verzögert. Zudem sind "baseball-bats" (wir mussten zu vollqualifizierten Namen übergehen) teuer und schwer herzustellen. Wie haben versucht alle Schlagleute das nutzen zu lassen, was sie wollten, aber das machte es sehr schwierig Statistiken zu führen und die scheinen nach Aussagen der Befürworter eine weitere Schlüsselkomponente von Baseball zu sein. Am Ende haben wir und darauf zurückgezogen, Äste zu nutzen, die um das Feld herum zu finden waren. Pinien funktioniert am besten, weil die Äste leicht von den Bäumen zu brechen sind. Und da die Hände vom Pinien-Harz klebrig werden, wird es leichter die Socke zu fangen, wenn man auf dem Feld ist.

Wo wir gerade beim Feld sind: Ein weiteres Problem, dass die Baseball-Freunde nicht vernünftig adressiert haben ist die Tatsache, dass mit einer Person werfend, einem Fänger und nur zweien auf dem Feld, der "Ball" zu oft dorthin geschlagen wird, wo kein Feldspieler ist, was zu viel zu viel Gelaufe und zu Spielen führt, die viel zu lang sind und viel zu hohe Ergebnisse haben. Letztendlich haben wir herausgefunden – ohne das wir nachvollziehen können, warum die ursprünglichen Baseball-Leute das nicht gesehen haben – das es fürchterlich ineffizient ist, nur einen Spieler als Fänger einzusetzen. Wenn die Astperson (Der Begriff "Batter" ist sowohl mehrdeutig als auch unangebracht durch die Änderungen an der Ausrüstung, die wir einführen mussten um das Spiel überhaupt nutzbar zu machen) einen Wurf verfehlt, dann nimmt er einfach selber die Socke und wirft sie der werfenden Person wieder zu. Auf diese Weise können alle vier Defensivspieler auf dem Feld bleiben, was einem sehr viel effizienteren Ressourceneinsatz entspricht - ein weiterer Beweis dafür, das Baseball nicht skalierbar ist.

Der Punkt, der der gesamten Idee von Baseball aber den Todesstoß versetzt ist dies: Selbst mit all diesen Verbesserungen macht das Spiel überhaupt keinen Spaß!

Wir haben Baseball ausprobiert und es hat nicht funktioniert!

Übersetzung Michael Mahlberg mit freundlicher Genehmigung des Autors wartet auf Genehmigung des Autors

Translation Michael Mahlberg with author's permission still waiting for permission from the author