Softwareveröffentlichungen: Wann ist gut genug wirklich gut genug?

by Rosario Disomma
Softwareveröffentlichungen: Wann ist gut genug wirklich gut genug? thumbnail

Im Juli fand zum dritten Mal in Folge die EuroPython 2013 in Florenz, Italien statt. Ein wenig über mich: Ich bin Italiener und ein Python-Programmierer, deshalb freue ich mich sehr, mehr über meine Erfahrungen bei der EuroPython zu teilen. Python hat eine erstaunliche Gemeinschaft, voll von einigen der klügsten und inspirierendsten Menschen in der IT-Branche. Nachdem ich sieben Jahre lang Teil dieser Gemeinschaft war, kann ich ehrlich sagen, dass Python-Konferenzen ganz auf die Menschen ausgerichtet sind. Die Menschen machen diese Gemeinschaft großartig.

Eine dieser inspirierenden Personen ist Alex Martelli, leitender Ingenieur bei Google und Mitglied der Python Software Foundation. Er hielt dieses Jahr eine Keynote auf der EuroPython mit dem Titel “Good Enough” is Good Enough! oder, wie er sagte und Richard Gabriel zitierte: der New Jersey-Ansatz, auch bekannt als “Worse is Better” im Gegensatz zum “MIT/Stanford-Ansatz, auch bekannt als “The Right Thing.” Ich war mir nicht sicher, worüber er sprechen würde, aber der Titel war faszinierend. Und was ich in den letzten sieben Jahren von Martellis Keynotes gelernt habe, ist, dass man, wenn er spricht, am besten zuhört, lernt und Notizen macht. Genau das habe ich also getan.

Die Keynote untersuchte zwei verschiedene Ansätze zur Softwareveröffentlichung. Der erste, “Das Richtige tun”, empfiehlt das Streben nach Perfektion (sich mit einer Softwareveröffentlichung zufriedenzugeben, die unterhalb von “perfekt” liegt, ist ein bedauerlicher Kompromiss). Der zweite, “Schlechter ist besser”, sagt, halte es einfach, gerade gut genug, starte früh, starte oft, hole viel Feedback (dies ist der „New Jersey-Ansatz“, weil Unix ein gutes Beispiel ist und in New Jersey geschrieben wurde).

Martelli erklärte, wie Richard Gabriel vier Kernwerte identifizierte, die beide Ansätze gemeinsam haben: Einfachheit, Korrektheit, Konsistenz und Vollständigkeit. Er fuhr fort zu erklären, dass das, was wirklich zählt, die Priorität ist, die diesen Werten gegeben wird. Gabriels Schlussfolgerungen können durch diese zwei Zitate zusammengefasst werden:

Die Philosophie des richtigen Tuns basiert darauf, den Experten zu erlauben, ihre Expertise auszuüben

Sache bis zum Ende, bevor die Benutzer sie in die Hände bekommen. 

Worse-is-better nutzt die natürlichen Vorteile der inkrementellen

Entwicklung. Stufenweise Verbesserung erfüllt einige menschliche Bedürfnisse…

Er ging noch weiter und wies darauf hin, wie Gabriels Interpretation dem nahe kommt, was Eric Raymond in seinem Buch „The Cathedral and the Bazaar“ beschrieb, in dem er zwei divergierende Modelle der Softwareentwicklung darstellte: die Kathedrale, wo die Experten das Sagen haben und alles um die Arbeit der Experten geht, im Gegensatz zum Basar, der von der Masse getragen und chaotisch ist, wo die Masse das Sagen hat und Personen einbezieht, die direkt beteiligt sind, aber unvermeidlich auch Personen, die nur aushelfen, weil sie die Produkte des Basars für unabhängige Arbeiten benötigen.

Natürlich lag Raymonds Schwerpunkt auf Fehlern und er glaubte, dass eine Million Augen den Fehlerentdeckungsprozess beschleunigen würden – und das ist genau der Punkt. Um eine Million Menschen darauf schauen zu lassen, müssen Sie den Code veröffentlichen. Sie müssen ihn in die reale Welt bringen und die Menschen ihn nutzen lassen. Wie Martelli sagte, wenn Sie nur “Perfektion” veröffentlichen wollen, wenn Sie wollen, dass der Experte das Expertending macht, dann benötigen Sie “Big Design Up Front”, perfekte Identifizierung der Anforderungen, perfekte Architektur, perfektes Design, perfekte Implementierungen usw. Und das wird ewig dauern! Aber noch wichtiger ist, das echte Leben spielt nicht immer mit.

Um Martelli noch einmal zu zitieren, „Das echte Leben tendiert dazu, nicht mitzuspielen.“ Anforderungen ändern sich, ebenso wie Architektur, Design und Implementierung. Iterative Entwicklung ist der Weg nach vorne. Etwas bereitstellen, Fehler beheben, verbessern, Versionskontrolle verwenden, Code-Überprüfungen, Codestil, Tests (wenn Sie nicht testen, bitten Sie um Probleme) und nicht zuletzt, dokumentieren Sie klar, was Sie getan haben.

Dies bedeutet nicht, dass wir unsere Erwartungen senken sollten. Wie Martelli betonte, „muss unser Traum groß bleiben, aber der beste Weg, diese Träume zu erreichen, ist, früh und oft zu veröffentlichen.“ Er fuhr fort, indem er Beispiele für perfekte Architekturen zeigte, die nie implementiert, veröffentlicht wurden oder die Schlacht gegen ihre nicht so perfekten Rivalen verloren, einschließlich, Xanadu vs WWW, TCP/IP vs ISO/OSI, MIT ITS vs UNIX.

Das Video der Keynote ist etwa eine Stunde lang, aber ich empfehle wirklich jedem, der Software entwickelt, es sich anzusehen. Auch wenn Sie mit den Schlussfolgerungen nicht einverstanden sind, ist es eine großartige Informationsquelle. Aufzeichnung der Keynote: http://www.youtube.com/watch?v=gHG9FRSlPxw

Meine große Frage nach der Keynote war: „Wann ist ‚gut genug‘ gut genug?‘ Wann kommt dieser Moment, mitten im Entwicklungsprozess, wenn man sagen kann: „Hey, es ist Zeit!“ Glücklicherweise war die Antwort auf meine Frage bereits in Martellis Keynote enthalten, nur darauf wartend, bemerkt zu werden.

Hinweis: hier ist ein Auszug aus dem Artikel von Eric Ries, dem Autor von „The Lean Startup“, Gut genug ist nie genug (oder doch?). Dies ist seine Definition von „minimum viable product.“

„Das minimal brauchbare Produkt ist die Version eines neuen Produkts, die es ermöglicht

ein Team, um die maximale Menge an validiertem Lernen mit dem geringsten Aufwand zu sammeln.”

Da ist es! Das ist die Antwort, die ich gesucht habe. Setzen Sie etwas ein, das das Leben von jemandem verbessert, etwas, das ein echtes Problem der realen Welt löst. Machen Sie es, sobald es in einem Zustand ist, der es Ihnen und Ihrem Team erlaubt, aus echten Interaktionen der Nutzer, echten Daten und echtem Feedback zu lernen. Lernen Sie damit umzugehen, dass die Nutzer in der echten Welt leben – und diese Welt ist unvollkommen. Aber die Alternative ist schlimmer; wenn Sie nur darauf warten, dass Ihre Software in einer Kathedrale zur Perfektion reift, werden Sie sie nie veröffentlichen.

Perfektion ist ein Prozess, kein Zustand. Um Eduardo Hughes Galeano zu paraphrasieren, ist Utopie wie der Versuch, den Horizont zu erreichen, den man nie erreichen wird, aber sie veranlasst uns, voranzuschreiten.