Das Web 2.0 Perpetual Beta Dilemma
... oder warum "perpetual beta" oft zu schlechter Software verleitet.
Einleitung
Die neue Offenheit der Kommunikation im Web 2.0 Zeitalter hat viele Vorteile. Einer davon ist, dass Webentwickler freimütig über ihre Programmier- und Anwendungsfehler in ihren Blogs schreiben. Doch leider steht dort immer öfter haarsträubendes, aufgrund dessen man den Eindruck bekommt, dass der Entwickler für seine Aufgabe nicht ausreichend qualifiziert ist.
Aussen Hui, innen Pfui
Halbfertige Internet-Anwendungen werden immer weiter "salonfähig", wenn sie nur nett aussehen. Dank dem Web 2.0 "Beta" wird es zur Normalität, dass Programmierer sich nur auf neue Features und "hübsche" Oberflächen konzentrieren. Doch das Fundament der Software ist brüchig und wackelig und die Sicherheit ist löchrig wie ein Schweizer Käse. Sieht ja von Aussen keiner. Also macht man das später, wenn viel Zeit ist. Man kann ja trotzdem schon mit der Website "Online" gehen.
Perpetual Beta was ist das?
"Perpetual Beta" ist ein Begriff den Tim O'Reilly geprägt hat. Er ging dabei von der Annahme aus, dass, in Zeiten des benutzerfreundlichen Web 2.0, die Software für Webanwendungen ständig (also über ihr gesamtes Software-Leben hinweg) an die Bedürfnisse der Anwender angepasst werden sollte. Dabei wird der übliche Zyklus der Softwareentwicklung aufgehoben, weil er für diese Aufgabe nicht praktikabel scheint. An der Software wird ständig weiterentwickelt, sie wird nie "fertig" und bleibt in einem fortwährenden halbfertigen Beta-Status (perpetual beta) - mit dem Anwender als permanentem Beta-Tester. (Eigentlich nennt Tim O'Reilly nur einen dramatisch verkürzten aber nicht abgeschafften Entwicklungszyklus, das geht aber meist unter...)
Konsequenzen für die Softwarequalität
Tatsächlich ist es so, dass man heute mit vergleichbar wenig Fachwissen Webanwendungen erstellen kann. Aus Zeitgründen wird an allem gespart, was für den Benutzer nicht direkt sichtbar ist. Testen und Finden der Fehler überlässt man dem Anwender. Doch viele Fehler, die die Sicherheit und Stabilität einer Webanwendung gefährden, werden von Anwendern nicht gefunden (können nicht gefunden werden), und werden daher nicht behoben. Die meist überlasteten Entwicklerteams haben genug damit zu tun, die von den Anwendern gemeldeten Fehler und Wünsche zu programmieren, statt nach weiteren Fehlern zu fahnden.
Das Internet ist kein freundlicher Ort für eine Web-Anwendung
Wenn man Web-Anwendungen schreibt hat man es aber mit einer weitaus komplexeren Software-Umgebung zu tun als vielen Entwicklern klar ist. Das Programm kommuniziert mit einem Haufen anderer Software. Ständig prasseln aus dem Internet irgendwelche Daten von Viren, Würmen und sonstigen Einbrechern gegen die Software, die dagegen "immun" sein muss. Das ist sie aber nicht automatisch. Vielen ist nicht bewusst, wie leicht ein Programm einer Webanwendung von Aussen manipuliert werden kann, wenn man nicht verschiedene Grundtechniken beherrscht und beachtet. Dazu kommen die üblichen Programmierfehler, die erst später auffallen ...
Operation am offenen Herzen
Bei einer Operation am offenen Herzen kann der kleinste Fehler fatale Folgen haben. Genau das macht man aber, wenn man direkt auf einem Live-System (mit echten Daten und echten Benutzern) Änderungen durchführt. Der Absturz des Systems ist da meist das kleinere Übel. Viel Schlimmer (weil nicht sofort entdeckt) sind aus Fehlern folgende Sicherheitslücken, durch die vertrauliche Daten preisgegeben oder manipuliert werden können.
Versprechen und Realität
Die Idee des "Perpetual Beta" ist verführerisch. Anwender nutzen die von ihnen gewünschte und für sie massgeschneiderte Software, die immer auf dem aktuellsten und bestmöglichsten technischen Stand ist. Die Realität ist oft leider anders. Tatsächlich werden sie mit unfertigen und viel zu früh veröffentlichten und schlampig entwickelten Softwareanwendungen konfrontiert, und werden permanent als Beta-Tester "missbraucht". Der Anbieter fühlt sich nicht mehr für die Qualitätssicherung verantwortlich, und verweist auf den Beta-Status. Der Leidtragende ist letztlich der Anwender.
Die Enterprise 2.0
Star-Trek Fans erinnern sich vielleicht noch an den Film "Generations". Am Anfang des Films fragt Captain Kirk in einer brenzligen Situation an Bord der Enterprise vergeblich nach "Torpedos", "Traktorstrahl" und der medizinischen Crew, die jedoch nicht vorhanden sind und immer erst "ab nächsten Dienstag" kommen.
Damals konnte man darüber schmunzeln. Bei heutigen Webanwendungen leider viel zu oft Realität.
Einleitung
Die neue Offenheit der Kommunikation im Web 2.0 Zeitalter hat viele Vorteile. Einer davon ist, dass Webentwickler freimütig über ihre Programmier- und Anwendungsfehler in ihren Blogs schreiben. Doch leider steht dort immer öfter haarsträubendes, aufgrund dessen man den Eindruck bekommt, dass der Entwickler für seine Aufgabe nicht ausreichend qualifiziert ist.
Aussen Hui, innen Pfui
Halbfertige Internet-Anwendungen werden immer weiter "salonfähig", wenn sie nur nett aussehen. Dank dem Web 2.0 "Beta" wird es zur Normalität, dass Programmierer sich nur auf neue Features und "hübsche" Oberflächen konzentrieren. Doch das Fundament der Software ist brüchig und wackelig und die Sicherheit ist löchrig wie ein Schweizer Käse. Sieht ja von Aussen keiner. Also macht man das später, wenn viel Zeit ist. Man kann ja trotzdem schon mit der Website "Online" gehen.
Perpetual Beta was ist das?
"Perpetual Beta" ist ein Begriff den Tim O'Reilly geprägt hat. Er ging dabei von der Annahme aus, dass, in Zeiten des benutzerfreundlichen Web 2.0, die Software für Webanwendungen ständig (also über ihr gesamtes Software-Leben hinweg) an die Bedürfnisse der Anwender angepasst werden sollte. Dabei wird der übliche Zyklus der Softwareentwicklung aufgehoben, weil er für diese Aufgabe nicht praktikabel scheint. An der Software wird ständig weiterentwickelt, sie wird nie "fertig" und bleibt in einem fortwährenden halbfertigen Beta-Status (perpetual beta) - mit dem Anwender als permanentem Beta-Tester. (Eigentlich nennt Tim O'Reilly nur einen dramatisch verkürzten aber nicht abgeschafften Entwicklungszyklus, das geht aber meist unter...)
Konsequenzen für die Softwarequalität
Tatsächlich ist es so, dass man heute mit vergleichbar wenig Fachwissen Webanwendungen erstellen kann. Aus Zeitgründen wird an allem gespart, was für den Benutzer nicht direkt sichtbar ist. Testen und Finden der Fehler überlässt man dem Anwender. Doch viele Fehler, die die Sicherheit und Stabilität einer Webanwendung gefährden, werden von Anwendern nicht gefunden (können nicht gefunden werden), und werden daher nicht behoben. Die meist überlasteten Entwicklerteams haben genug damit zu tun, die von den Anwendern gemeldeten Fehler und Wünsche zu programmieren, statt nach weiteren Fehlern zu fahnden.
Das Internet ist kein freundlicher Ort für eine Web-Anwendung
Wenn man Web-Anwendungen schreibt hat man es aber mit einer weitaus komplexeren Software-Umgebung zu tun als vielen Entwicklern klar ist. Das Programm kommuniziert mit einem Haufen anderer Software. Ständig prasseln aus dem Internet irgendwelche Daten von Viren, Würmen und sonstigen Einbrechern gegen die Software, die dagegen "immun" sein muss. Das ist sie aber nicht automatisch. Vielen ist nicht bewusst, wie leicht ein Programm einer Webanwendung von Aussen manipuliert werden kann, wenn man nicht verschiedene Grundtechniken beherrscht und beachtet. Dazu kommen die üblichen Programmierfehler, die erst später auffallen ...
Operation am offenen Herzen
Bei einer Operation am offenen Herzen kann der kleinste Fehler fatale Folgen haben. Genau das macht man aber, wenn man direkt auf einem Live-System (mit echten Daten und echten Benutzern) Änderungen durchführt. Der Absturz des Systems ist da meist das kleinere Übel. Viel Schlimmer (weil nicht sofort entdeckt) sind aus Fehlern folgende Sicherheitslücken, durch die vertrauliche Daten preisgegeben oder manipuliert werden können.
Versprechen und Realität
Die Idee des "Perpetual Beta" ist verführerisch. Anwender nutzen die von ihnen gewünschte und für sie massgeschneiderte Software, die immer auf dem aktuellsten und bestmöglichsten technischen Stand ist. Die Realität ist oft leider anders. Tatsächlich werden sie mit unfertigen und viel zu früh veröffentlichten und schlampig entwickelten Softwareanwendungen konfrontiert, und werden permanent als Beta-Tester "missbraucht". Der Anbieter fühlt sich nicht mehr für die Qualitätssicherung verantwortlich, und verweist auf den Beta-Status. Der Leidtragende ist letztlich der Anwender.
Die Enterprise 2.0
Star-Trek Fans erinnern sich vielleicht noch an den Film "Generations". Am Anfang des Films fragt Captain Kirk in einer brenzligen Situation an Bord der Enterprise vergeblich nach "Torpedos", "Traktorstrahl" und der medizinischen Crew, die jedoch nicht vorhanden sind und immer erst "ab nächsten Dienstag" kommen.
Damals konnte man darüber schmunzeln. Bei heutigen Webanwendungen leider viel zu oft Realität.
Geschrieben von af in am: Mittwoch, 14. Februar 2007
Permalink
Nächster Artikel: The IT Crowd Helpdesk
Vorheriger Artikel: DRM in Windows Vista
