Ein Plädoyer für schlampigere Software

Nein, damit ist natürlich keine Software gemeint, die voller Fehler ist, unberechenbar, Festplatte und Hauptspeicher gnadenlos mit Daten vollmüllt etc. Der Titel ist meine persönliche Interpretation einer Rede, die Adam Bosworth (Ex-Microsoft, Ex-BEA, jetzt Google) kürzlich gehalten und in seinem Weblog veröffentlicht hat: ISCOC04 Talk. Die ist (1) wahnsinnig gut, (2) wundervoll provokant und (3) passt so perfekt zu meiner These "Die Zukunft des Internets: Bastler am Werk", dass ich mir nicht verkneifen kann, ein paar der besten Auszüge davon noch mal zu präsentieren.

Im Kern lautet seine These oder besser: sein Schlachtruf:

Vergesst die ganzen Standards jahrelang tagender Kommitees, die nur noch in meterdicken Stapeln Papier dokumentiert werden können. Wir brauchen ein paar simple Standards wie HTTP, HTML, RSS,  REST-Style-Webinterfaces etc. Wir brauchen tolerante, robuste Software, die nicht sofort einen Würgreiz bekommt, wenn im Input mal eine Klammer nicht korrekt geschlossen wird. Und gutt iss ...

Klingt mehr nach einem jugendlichen Hacker als nach einem alten wettergegerbten Softwarearchitekten, der bei Microsoft immerhin Access und den Explorer mit an die Rampe geschoben hat und bei BEA CTO war, nicht? Aber der Mann hat tatsächlich soooo Recht. Wenn er auch ein bisschen übertreibt. Aber das gehört dazu.

Hier mal ein paar Details (sozusagen Best of Bosworth)...

Der gute Mann hat (nicht als Erster) eine Trennung in der Softwarewelt entdeckt, die in mancher Hinsicht ähnlich fundamental ist, wie die zwischen Open-Source- und Closed-Source-Anhängern.

Ein Teil der Software-Welt ist geradezu verliebt in "perfekte" Standards, die möglichst schon im Vornherein alle Eventualitäten abdecken sollen (aber das nie tun), möglichst alle am Standardisierungsprozess Beteiligten glücklich machen sollen und so präzise wie nur möglich definiert sind. Ein anderer Teil will möglichst nur ein paar funktionierende Werkzeuge, locker skizzierte Regeln vom Detailiertheitsgrad der 10 Gebote und dann loslegen. Hat beides Vor- und Nachteile und tritt oft auch in Mischformen irgendwo zwischen diesen beiden Polen auf. Tatsächlich spricht meines Erachtens aber viel für eine ernsthaftere Beschäftigung mit der zweiten "Schule".

I’m going to talk about the virtues of KISS which I’ll conveniently describe as keeping it simple and sloppy and its effect on computing on the internet. [eine neue Umschreibung des KISS-Prinzips; gefällt mir]

It is an ironic truth that those who seek to create systems which most assume the perfectibility of humans end up building the systems which are most soul destroying and most rigid, systems that rot from within until like great creaking rotten oak trees they collapse on top of themselves leaving a sour smell and decay. We saw it happen in 1989 with the astonishing fall of the USSR. Conversely, those systems which best take into account the complex, frail, brilliance of human nature and build in flexibility, checks and balances, and tolerance tend to survive beyond all hopes.

So it goes with software. That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow while that software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion.

Bosworth beläßt das nicht bei dieser These sondern bringt schöne Beispiele aus der Welt der Kalkulationssoftware (anyone out there remembering "Improv"; ich ja), Programmiersprachen (Ada, anyone?) etc.

Was bei mir naturgemäß allerdings noch mehr "zum Schwingen bringt", sind die Standards für Datenaustausch und vernetzete Datenverarbeitung im Web:

On the one hand we have RSS 2.0 or Atom. The documents that are based on these formats are growing like a bay weed. Nobody really cares which one is used because they are largely interoperable. Both are essentially lists of links to content with interesting associated metadata. Both enable a model for capturing reputation, filtering, stand-off annotation, and so on. [...]

On the other hand we have the world of SOAP and WSDL and XML SCHEMA and WS_ROUTING and WS_POLICY and WS_SECURITY and WS_EVENTING and WS_ADDRESSING and WS_RELIABLEMESSAGING and attempts to formalize rich conversation models. Each spec is thicker and far more complex than the initial XML one. It is a world with which the IT departments of the corporations are profoundly comfortable. It appears to represent ironclad control. It appears to be auditable. It appears to be controllable. [...]

Und jeder, der sich ein wenig um die Standards der zweiten Gruppe kümmert, weiß, in welch barmenswerten Zustand ihre Akzeptanz ist. Vielleicht (nein sicherlich) wird es Unternehmen geben, für die diese Big-Standards wichtig sind, die die IT-Backbones ganzer Konzerne darum aufbauen. Aber langsam, unendlich langsam. Und im freien Web geht derzeit die Post ab: da wird nicht jahrelang geplant und verhandelt.

Sieht ein Entwickler eine neue Anwendungsmöglichkeit für schon bestehende Software und Services legt er los, nutzt die bestehenden Services - meist ganz neu und auf eine Art, wie sie deren Betreiber nie vorhergesehen hat, schafft neuen Wert und bringt etwas neues, Schönes in die Welt. Er dengelt das mit RSS- oder Atom-Feeds, offenen REST- (manchmal auch SOAP-)APIs und ein bisschen PHP, Python oder Perl zusammen und fertig ist die Luzi. Hat sein Werk keinen Erfolg, wird es eben ignoriert. Hat es zu großen und bricht unter der Last zusammen, muss es eben refaktoriert werden. Vielleicht werden ein paar Teile dann ein Java nachentwickelt, vieleicht ein ordentlicher Applikationsserver aufgesetzt. Klar, ist so etwas sinnvoll. Aber eben erst jetzt.

Und das machen nicht ein paar Dutzend Entwickler so, sondern Tausende, verbunden über ihre Weblogs, Wikis, SourceForge und offene Versionskontrollsysteme. Dafür ist nicht mal Open Source nötig, dafür reichen offene, transparente Schnittstellen (wie die Beteiligung von Amazon, Google, eBay etc. in solchen loose gekoppelten Anwendungsnetzen zeigt). Diese Entwicklung hat eine ungeheure Dynamik, mit der die Monster-Standards einfach nicht mithalten können. Diese haben allerdings auch ihre Daseinsberechtigung (sie werden aber die Weiterentwicklung des Webs wegen ihrer Trägheit nicht groß beeinflussen):

I would like to say that we are at a crossroads, but the truth is never so simple. The truth is that people use the tools that work for them. Just as for some programmers the right tool is PHP and for others the right tool is Java so it is true that for some programmers the right tool is RSS and for others it is WS-*. There is no clear “winner” here. What I am sure about is the volumes and the values. The value is in the information and its ability to be effortlessly aggregated, evaluated, filtered, and enhanced.

Das Geheimnis ist Simplizität und Flexibilität. Nochmal Bosworth dazu:

As I said earlier, I remember listening many years ago to someone saying contemptuously that HTML would never succeed because it was so primitive. It succeeded, of course, precisely because it was so primitive. Today, I listen to the same people at the same companies say that XML over HTTP can never succeed because it is so primitive. Only with SOAP and SCHEMA and so on can it succeed.

Man kann gerne auch die Beispiele SMS oder Weblog nehmen. SMS ist ein schrecklich primitives Kommunikationsmittel ganz knapp oberhalb des Telegramms - und ein irrsinniges Geschäft. Weblogs sind fürchterlich primitive CMS-Systeme - und furchtbar populär.

Und das sind die entscheidenden Kriterien auch für die künftig erfolgreichen Technologien. Weil das das ist "was die Leute wollen". Und spätestesten mit dem Aufkommen der großen Foren-Communities und jetzt mit den Weblogs, mit Orkut, OpenBC, mit Flickr etc. ist auch im Web entscheidend, was die Leute wollen und was sie selbst beitragen wollen - und mit den verfügbaren Werkzeugen beitragen können:

“My mother never complains that she needs a better client for Amazon. Instead, her interest is in better community tools, better book lists, easier ways to see the book lists, more trust in the reviewers, librarian discussions since she is a librarian, and so on”.

This is what will be new. In fact it already is. You want to see the future. Don’t look at Longhorn. Look at Slashdot. 500,000 nerds coming together everyday just to manage information overload. Look at BlogLines. What will be the big enabler? Will it be Attention.XML as Steve Gillmor and Dave Sifry hope? Or something else less formal and more organic? It doesn’t matter. The currency of reputation and judgment is the answer to the tragedy of the commons and it will find a way. This is where the action will be. Learning Avalon or Swing isn’t going to matter. Machine learning and inference and data mining will. For the first time since computers came along, AI is the mainstream.

I find this deeply satisfying. It says that in the end the value is in our humanity, our diversity, our complexity, and our ability to learn to collaborate. It says that it is the human side, the flexible side, the organic side of the Web that is going to be important and not the dry and analytic and taxonomical side, not the systematized and rigid and stratified side that will matter.

In the end, I am profoundly encouraged and hopeful that the growth on the web is one which is slowly improving the civility and tenor of discourse. Just as Porn seems to be an unpleasant leading user of technology, so does crude and vituperative communication seem to be a pattern for early adopters and it is a relief to see that forms of governance, trust and deliberation are now emerging.

OK, wem das zu optimistisch, blauäugig erscheint, sollte dran denken, dass das immerhin ein Technologie-Manager geschrieben hat. Und noch einen drauf:

There are those who will say that all this is utopian. If Utopian means not being afraid to dream, then indeed it is. So was Tim’s initial vision of universal access to information. So is Google’s mission. T.E Lawrence wrote in the Seven Pillars of Wisdom,

“All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dream with open eyes, to make it possible”

I encourage all of you to act your dreams with open eyes. I encourage all of you to dream of an internet that enables people to work together, to communicate, to collaborate, and to discover. I encourage all of you to remember, that in the long run, we are all human and, as you add value, add it in ways that are simple, flexible, sloppy, and, in the end, everything that the Platonists in you abhor.

Gefällt mir. Seufz! Muss aber natürlich nicht jedem gefallen, was hier steht. Manch professioneller Entwickler oder Systemarchitekt wird die Hände über dem Kopf zusammenschlagen. Aber lesenswert ist es allemal.

Marc Canter hat eine saftige Reprise dazu geschrieben: Dear Mr. Bosworth, Danny Ayers auch, und Sriram Krishnan haut (noch heftiger) in die selbe Kerbe wie Bosworth selbst. Die Meinungen gehen auseinander. Wenn ich mir die bisherigen Diskussionsbeiträge ansehe (und Bosworth war ja nicht der erste, der sich "mehr Lässigkeit" auf die Fahne geschrieben hat) scheint es aber tatsächlich auch bei den seriösen Vertretern der Software-Zunft ein wachsendes Unbehagen mit immer komplexeren, immer unhandlicheren, rigideren Standards zu geben. Gut so!

Comments

[Benjamin Reitzammer]

Tim Bray, einer der XML "Götter", hat etwas aehnliches zur Atom Entwickler Gemeinde gesagt. Im übertragenen Sinne: "Nehmt Atom so wie es jetzt ist, und macht daraus einen Standard, anstatt noch Jahre mit einer sinnlosen Prozedur zu verschwenden". Interessant auch sein Schlusswort: "You don’t think this can change the world? Just watch."

Die neue Definition von KISS hat ein paar sehr bekannte Fürsprecher.

Siehe http://www.tbray.org/ongoing/When/200x/2004/11/11/AtomInnovation

[Markus Breuer]

danke für den link, benjamin.

mir gefällt das original noch besser als deine übersetzung (sorry):

The worst thing the Atom WG could possibly do would be to spend another year or two trying to invent wonderful new syndication goodies. What on earth would give us the idea that we’re smart enough to predict what features the world is going to want? Our job is to write down what we already know works, to do it as cleanly and clearly as possible in as few pages as possible, then get out of the way.

was meine meinung zu bray allerdings wieder etwas gesenkt hat, war seine antwort auf den rant von sriram zum thema XML (in dessen antwort auf bosworth' rede):

# re: Tyranny of the geeks 11/20/2004 1:27 AM Tim Bray
XML markup is case-sensitive because the cost of monocasing in Unicode is horrible, horrible, horrible. Go look at the source code in your local java or .Net library.

Also, not only is it expensive, it's just weird. The upper-case of é is different in France and Quebec, and the lower-case of 'I' is different here and in Turkey.

XML was monocase until quite late in its design, when we ran across this ugliness. I had a Java-language processor called Lark - the world's first - and when XML went case-sensitive, I got a factor of three performance improvement, it was all being spent in toLowerCase(). -Tim

ein (m.e.) extrem nerviges "feature" damit zu rechtfertigen "das ließ sich aber schneller implementieren" ist so was von ... mir fehlen die worte ... "nerdig" vielleicht? lasst uns doch einfach alle unser texte direkt in postscript schreiben. spart enorm rechenzeit beim ausdruck.

[Benjamin Reitzammer]

Naja, ich würde es nur nervig nennen, wenn man XML unbedingt per Hand erzeugen will. Und die Frage zu stellen ob das Sinn macht, ob XML dafür vorgesehen ist, kann leicht einen flamewar erzeugen.
Ich für meinen Teil, finde es nicht schlimm das XML case sensitive ist (wie Bray schreibt). Ich bin sogar erst nach einiger Zeit darüber gestolpert, und hatte vorher nie Probleme damit.
Und ausserdem hat er es ja noch anders begründet. Wobei ich hier gestehen muss, dass ich (viel) zu wenig ueber Unicode weiss, als dass ich da etwas dazu sagen kann.

Ich denke Standards sollten Aspekte, die technische Probleme verursachen können, wozu case sensivity anscheinend gehört, durchaus berücksichtigen und den Benutzer evtl einschränken.
Das ist ja schließlich der Sinn von Standards. Einschränken und Festlegen, damit möglicht viele Leute zusammenarbeiten und sich untereinander verstehen können.