Ich interessiere mich nicht besonders stark für Fussball. Eher mehr für die Aufmerksamkeit, die er in den Medien genießt. In den letzten Tagen konnte man nicht umhin, die Schlagzeilen in den meisten Zeitungen – zumindest im Sportteil – zur Kenntnis zu nehmen.
Und da geht es nicht nur um Bild oder Kronenzeitung, nein auch in der Presse und im Standard waren die Aussagen von Maradona zu lesen. „Deutschland möge die Koffer packen“, „Schweinsteiger sei zu nervös“, „bittere Revanche for die letzte Begegnung“, „Gegen die Galaaufstellung haben die Deutschen keine Chance“.
–
Yeah, suck it to them! Das ist die richtige Antwort auf solche Sprüche. Und wenn solch ein Topteam nicht einmal ein Tor schießen kann, ja nicht einmal der teuerste Spieler auf der Welt in das Tor hineintrifft, dann freut es mich tierisch, den Gesichtsausdruck von Maradona zu sehen.
Ja, nichts gegen die Mannschaft der Argentinier. Die hat gekämpft und manchmal auch Klasse aufblitzen lassen. Dass sie bei der deutschen Abwehr, – das erste Mal, dass mir eine Abwehr gefallen hat – abgemeldet war, ist halt einerseits der Erfolg der deutschen Strategie oder auch Taktik, andererseits ist es aber auch ein Zeichen, dass ein guter Fussballspieler nicht automatisch ein guter Trainer sein muss und schon gar nicht ein guter Stratege.
–
Endlich ist er zurechtgestutzt.
Und wenn ich denke, wie viele Anhänger er hat, dann sind das halt die Leute, die immer wieder so leicht vergessen. *
[von http://www.bz-berlin.de/archiv vom 21.4.2004]
Buenos Aires – Argentinien ist erleichtert. Ihr Nationalheld Diego Maradona, 43, liegt zwar immer noch auf der Intensivstation der Privatklinik „Clinica Suiza Argentina“, kann aber nach Angaben seiner Ex-Frau wieder alleine atmen. Im ärztlichen Bulletin ist dagegen noch von künstlicher Beatmung die Rede. Der Zustand hat sich nach dem Herzinfarkt stabilisiert, die Antibiotika wirken. Der Schock aber: Offenbar war beim erneuten Kollaps des Weltmeisters von 1986 wieder Rauschgift im Spiel. Die staatliche argentinische Nachrichtenagentur „Telam“ meldete, dass in Maradonas Urin Reste von Kokain gefunden wurden. Der Kokaingehalt sei so hoch, dass er nur bei einem an regelmäßigen Drogenkonsum gewöhnten Körper äußerlich unbemerkt geblieben sein könne.
Maradonas Leibarzt Dr. Alfredo Cahe versichert weiter: „Es hat gar nichts damit zu tun. In letzter Zeit hat er kein Kokain konsumiert.“
Der stark übergewichtige Weltmeister von 1986 war in den letzten Jahren immer wieder durch Drogen-Exzesse aufgefallen, kam gerade erst von einer langen Entziehungskur auf Kuba. Trotzdem verehren ihn die Argentinier wie keinen anderen.
Dutzende Fans umlagern noch immer die Klinik, die von der Polizei hermetisch abgeriegelt wird. Sportminister Roberto Perfumo und Staatspräsident Nestor Kirchner schickten Genesungswünsche: „Ich hoffe, dass er sich schnell erholt. Wie allen Argentiniern, so verursacht dies auch mir Schmerzen. Wir müssen ihm beistehen. Er ist eine großartige Person.“
Wie ernst es um „Dieguito“ stand, wurde durch ein Mitglied des Priester-Notdienstes bekannt. Er hatte dem Nationalhelden schon die „letzte Ölung“ gegeben.
*) Die einzige Person, der ich Kokainkonsum nachsehe, ist Konstantin Wecker. Der hat aber später auch selbst gesagt, dass man die Finger davon lassen sollte.
Die einfachste Metrik ergibt sich noch immer aus dem PTR. Das steht für Problem Tracking Report. Dabei werden die gefundenen Probleme mit einigen Zusatzinformationen in einer Datenbank erfasst. Welche Zusatzinformationen hier nötig sind, wird in einem späteren Artikel erläutert.
Heute interessiert uns nur das Auftreten des Problems, das Datum und der Schweregrad. Natürlich sind Projektidentifikation und nähere Problembeschreibung der eigentliche Hinweis darauf, was mit dem Problem zu geschehen hat. Doch im Sinne der Metrik ist das Datum und der Schweregrad ausreichend.
Erfassen wir die auftretenden Probleme kumulativ, was sich leicht bewerkstelligen läßt, so lassen sich die kumulierten Probleme über einer Zeitachse auftragen. Eine Skalierung in Wochen erscheint zweckmäßig. Bei dieser Erfassung werden weder Feiertage noch unterschiedliche Testbelegschaften berücksichtigt.
Aus der Kurve lässt sich ziemlich viel über die Güte eines Projektverlaufes aussagen. Sie wird umso wichtiger, je größer die Projekte sind. Wenn wir von einer Programmgröße von 2000 Function Points ausgehen (das könnten 100 000 C++ Lines of Code sein) , so dürfen wir für n_geschätzt durchaus mit 700 – 1000 auftauchenden Problemen rechnen.
Das sind nur die, welche auf den endgültigen Entwickler-unabhängigen Funktionstest und Betreibbarkeitstest warten. Im Programm selbst steckt insgesamt in etwas die vierfache Problemmenge. Die wurden allerdings hoffnungsvollerweise schon in früheren Phasen des Projekts gefunden und behoben.
In der Kurve gibt es einen Wendepunkt. Der ist idealerweise ungefähr im Bereich der Hälfte der geschätzten Fehler. Das muss nicht unbedingt so sein. Doch die Hälfte der geschätzten Fehler sollten wir in der Hälfte der Zeit gefunden haben, die für den Testbetrieb geplant war. Erreichen wir dieses Ziel nicht, so dürfen wir davon ausgehen, dass wir entweder
- mehr Fehler in der Lebensphase des Programmes zulassen müssen – oder
- zusätzliche Testzeit bereitstellen müssen.
Beide Möglichkeiten sind mit Kosten verbunden.
Probleme, sowohl gefundene als auch nicht gefundene, lassen sich in € umrechnen und bewerten.
Anmerkung: In der Praxis ist es oft der Fall, dass die Kosten für Test und die Folgekosten von nicht gefundenen Fehlern von verschiedenen Gruppen, Abteilungen, ja auch Firmen getragen wird. Dies verhindert in der Regel eine integrale Sicht auf die Kostensituation und führt dazu, dass Test nicht ausreichend budgetiert wird. Diesem Umstand wird durch eine neue Strategie, dem „economic testing“ Rechnung getragen.
Während die Probleme die kleine Münze darstellen, kann ein weiterer Begriff aus dem Testbereich als Banknote gedacht werden: es handelt sich um den Testfall.
Ein notwendiger Testfall stellt eine Schuld dar, solange er noch nicht zufriedenstellend betestet wurde. Dies ergibt sich aus dem Begriff notwendig. Es gibt verschiedene Möglichkeiten Testfälle zu definieren. Man kann sie aus den Anforderungen herausdestillieren. Man kann sie analytisch bilden, in dem man eine möglichst große Menge von Programm-Möglichkeiten damit abdecken kann. Die bis jetzt als sparsamste Variante erkannte Art, Testfälle zu bilden, leitet sich von einer Risikobetrachtung ab.
Welche Fehler passieren am häufigsten? Welche Fehler richten den größten Schaden an? Das Produkt aus Häufigkeit mal Schadenswirkung gibt eine Kenngröße an, welche die Programmszenarien auszeichnet, welche unbedingt getestet werden müssen.
Ein derartiger Testfall läßt sich daher relativ einfach in € bewerten. Schadenswirkung mal Häufigkeit läßt sich in €/Jahr errechnen. (Wie oft wird das Szenario pro Jahr im normalen Betrieb durchgeführt? Jährliche Läufe, Monatliche Läufe, 10 000 Requests/Tag) Dieser Betrag wird mit der durchschnittlichen Fehlerhäufigkeit multipliziert. Das ist eine Prozentzahl, die sich aus den Kennwerten des Testbetriebes ergibt. Ob man hier nun von Reliability oder Error Prevention oder Error Removal Rate spricht, ist nur eine Geschmacksfrage. In jedem Fall geht man von einer verbleibenden Restfehlermenge aus, welche je nach Anwendung zwischen mehreren Prozent- und Promillebereichen liegt. Bei einem durchschnittlichen Lebenszyklus von 4 Jahren und unter Berücksichtigung der Kompression (eine Linearisierung des Fehlerfindungsverlaufes) lässt sich der Restfehleranteil noch durch 4 dividieren.
Nehmen wir also im obigen Beispiel an, dass ein Fehler, welcher einmal im Jahr schlagend werden kann, 100 000 € Schaden bewirkt, und wir von einer Restfehlermenge von 3% ausgehen, so rechnen wir:
Erwartete Fehler in Test: 1000
Gesamtfehler im Programm: 4000
Restfehlermenge: 3% Zielvorstellung
Fehlerschaden/Jahr: 100 000 €
Wahrscheinlichkeit: 0,75%
Fehlerrisiko 1. Jahr: 750 €
Fehlerrisiko insgesamt: 3000 €
In dieser Rechnung sind allerdings keine Folgekosten hinsichtlich der Berichtigung des Fehlers enthalten. Um den Fehler nicht zu wiederholen, sind entsprechende Testläufe und ein neues Deployment notwendig. Das bedeutet, dass das Fehlerrisiko brutto für netto angenommen werden muss und allfällige Kosten des Testes nicht berücksichtigt werden müssen.
Das obige Beispiel klingt vergleichsweise harmlos, trotz der großen Schadenssumme scheint es sich nur um eine Art Versicherungszocke zu handeln. Interessanterweise geht die Gesamtzahl der Fehler auch gar nicht in die Rechung ein.
Schlimmer sieht die Risikofrage bei Abläufen aus, die im Tag mehrere Male durchlaufen werden. Hier sind es vor allem diejenigen Probleme, um die man herumarbeiten kann, welche große Kosten verursachen. Der Work-Around verschlingt vielleicht 2 Minuten mehr Arbeitszeit, die nicht registriert wird. Durch den Work-Around wird aber die Dringlichkeit der Fehlerbehebung in den Hintergrund gedrängt und es entstehen schleichende Kosten, welche weit über die oben angesetzte Summe von 100 000 € hinausgehen.
An dieser Stelle sollen keine weiteren Berechnungshinweise mehr gegeben werden. Es reicht, wenn man sich bewusst wird, dass Probleme und Testfälle ihre unmittelbare Entsprechung in € haben. Auch wenn es oft sehr schwer ist, diesen Zusammenhang einem Projektleiter zu vermitteln, so hilft es sehr, wenn es darum geht, die durchzuführenden Testmassnahmen zu planen.
Wenn wir ein Programm testen, stoßen wir auf Fehler. Bevor wir aber wissen, dass es sich um einen Fehler handelt, merken wir nur, dass wir als Tester auf etwas Unerwartetes stoßen. Etwas passiert nicht so, wie wir es erwarten.
Dies trifft auch auf automatische Testdurchführung zu. Das Ergebnis des Testdurchlaufes stimmt nicht mit einem vorgegebenen Resultat überein.
Jetzt stellt sich heraus, dass ein beobachteter Effekt zwei verschiedene Kriterien erfüllen muss, um als Fehler klassifiziert zu werden.
- Er überrascht uns. Wir selbst glauben, dass etwas falsch ist.
- Es herrscht Konsens von mehreren Seiten, dass hier etwas unrichtig ist.
Liegt nur die erste Bedingung vor, so verwenden wir besser einen anderen Begriff. In mehreren Firmen wird der Begriff PROBLEM bevorzugt.
Ein PROBLEM ist eine Unstimmigkeit, die aufgelöst gehört.
Die zweite Bedingung spricht von mehreren Seiten. Damit ist der Tester (T), der Entwickler (E) und der Anforderer (A, der Vertreter des Auftraggebers, welcher die Funktionalität des Programmes beschrieben hat) gemeint. Es ergeben sich jetzt folgende Möglichkeiten:
(In untenstehender Notation bedeutet 0, dass kein PROBLEM festgestellt wurde, 1 hingegen, dass die jeweilige Person einen Fehler konstatiert.)
- T=0 E=0 A=0 Es wird kein PROBLEM und auch kein Fehler konstatiert.
- T=0 E=0 A=1 Eine unangenehme Situation, die aber nicht im Zuge des Testens erkannt wird. Hier handelt es sich um eine Entwicklung auf ein „moving target“, dieser Umstand verteuert jede Software-Entwicklung.
- T=0 E=1 A=0 In dieser Situation freut sich der Entwickler, der selbst irgendwann seinen eigenen Implementierungsfehler festgestellt hat, dass sonst noch niemand seinen Fehler entdeckt hat. Er wird versuchen, die Nachbesserung in die nächste Version einfließen zu lassen.
- T=0 E=1 A=1 Das ist eine Testsituation, bei der nicht das Programm sondern die Testdurchführung getestet wurde. Bewusst eingebaute Fehler sollen die Zuverlässigkeit des Software-Tests überprüfen. Ich habe diesen Fall in der Realität noch nie vorgefunden, doch wird er in manchen Vorträgen über Software-Test erwähnt. Die Vorgangsweise der bewussten Fehlereinstreuung ist bei Hardwaretests immer dann notwendig, wenn es um sensible und lebensbedrohende Apparaturen geht.
- T=1 E=0 A=0 Ein Streitfall. Hier steht der Tester gegen den Rest der Welt. Solche PROBLEME bleiben ungelöst, wenn der Tester nicht überzeugt werden kann, dass seine Beanstandung falsch gewesen ist.
- T=1 E=0 A=1 Ein Entwicklungsfehler. Etwas ist in der Implementierung falsch. Nun kann das Problem als ERROR klassifiziert werden. Der Anforderer muss oft gar nicht konsultiert werden, wenn der Entwickler bereits selbst mit der ERROR-Klassifikation übereinstimmt.
- T=1 E=1 A=0 Ein Fehler in der Anforderung. Der ursprüngliche Wunsch des Anforderers war sachlich unrichtig. Aus Gründen der Unterscheidbarkeit und auch wegen der unterschiedlichen Behandlung bei der Korrektur wird hier nicht von ERROR gesprochen sondern von einer Anforderungsänderung – CHANGE REQUEST
- T=1 E=1 A=1 Auch hier tritt der Fall der Anforderungsänderung ein. Es wird aber in der Regel keine langatmige Diskussion mit dem Anforderer notwendig sein.
(Über CHANGE-REQUEST wird später noch gesprochen.)
Wenn wir nun die unterschiedlichen Fälle betrachten, so stellen wir fest, dass in einigen Fällen die Zusammenarbeit von Entwicklern und Testern in eine Streiterei ausarten kann. Der Entwickler gibt ungern einen Fehler zu, der Tester wird an der Anzahl der gefundenen Fehler gemessen und „freut sich“, wenn er wieder etwas gefunden hat. Der Entwickler kann allenfalls auf CHANGE-REQUEST plädieren, womit der schwarze Peter dem Anforderer zugespielt wird. Dieser hat an sich eine Grundverantwortung über die Richtigkeit eines Programmes. Er kann sich also höchstens aufregen, warum man diesen Fehler nicht schon viel früher entdeckt hat.
Hier muss zur Verteidigung des Anforderers festgestellt werden, dass manche Effekte erst dann wirklich sichtbar werden, wenn man sie mit eigenen Augen am Bildschirm sieht. Man kann auch sagen, wenn die Vorstellung Gestalt angenommen hat, werden Fehler erst sichtbar.
Wenn wir bei komplexeren Programmen mit mehreren Tausend PROBLEMEN zu tun haben, wird es notwendig sein, dass die Vorgangsweise im Fall 5 und 7 reglementiert wird. Es darf nicht zu mehreren Tausend Streitigkeiten kommen.
Hier bestimmt die Kultur eines Software-Hauses die Effizienz des gesamten Teams. Wird das Gesamtziel in den Vordergrund gestellt, so darf die Produktivität des Testvorganges nicht an der Anzahl der gefundenen Fehler gemessen werden.
Viel mehr ist derjenige Tester der erfolgreichste, welcher die meisten Fehler behoben bekommt.
Damit wird dem Tester aber auch die Aufgabe zugeteilt, das aufgetretene PROBLEM so umfassend wie möglich zu beschreiben, damit die Reproduzierung des PROBLEMs und die Behebung für den Entwickler erleichtert werden.
Darüber hinaus führt diese Überlegung zum Begriff des Schweregrads eines Fehlers. Dieser wird später behandelt.
——————————————–
Vor 22 Jahren arbeitete ich für ein renommiertes deutsches Unternehmen, welches über eine österreichische Tochterfirma in die Sovjetunion verkaufte. Der Verkauf lief über zentralistische Außenhandelsunternehmungen. Diese benötigten eine Proforma, die dann entsprechend „getuned“ wurde, um den preislichen und gleichzeitig technischen Anforderungen zu entsprechen.
Die Auftragsbestätigung und das Rechnungswesen lief über die österreichischen bzw. deutschen Zentralcomputer. In Wien war das eine Nixdorf-Anlage.
Zum Schreiben der Proformas (bzw. Spezifikationen, ein dem Techniker genehmerer Ausdruck) wurden seit jeher Schreibmaschinen verwendet. Tippex war ein Problem, da es in den Proformas keine Korrekturen geben sollte. Trotzdem kannte ich einen Kollegen einer anderen Firma, der seine Proformas mit Papier, Schere und Uhu-Stick zusammenbastelte.
Als große Errungenschaft hatte die Chefin der EDV in Wien ein Programm „gebastelt“, welches die Schreibmaschine durch einen PC ersetzen ließ. Von der Nixdorf-Anlage gab es einen Abzug der Stammdatei-Artikel. Artikelnummer, Kurzbezeichnung, Preis.
Jetzt konnte man sich die Artikel durch Eingabe der Artikelnummer zusammensuchen und musste nicht mehr im Prospekt nachschlagen. Für meinen damaligen Chef war das eine große Verbesserung, ich schlug die Hände über dem Kopf zusammen und bastelte aus lauter Verzweiflung mein eigenes System.
Warum war ich verzweifelt? Das Programm wies drei hauptsächliche Fehler auf. Zwei davon waren Analyse-Fehler, einer bestand in der Nichterfüllung von nicht-funktionalen Anforderungen.
Die Analysefehler waren folgende:
Die Anwendungsfälle (use cases) des Programmes waren nur oberflächlich untersucht worden. Es fehlte der Anwendungsfall „Proforma überarbeiten“. Das führte dazu, dass man
- eine einmal geschriebene Spezifikation nicht verwenden konnte, um eine ähnliche Spezifikation mit zwei Teilen mehr oder weniger zu erstellen.
- nichts aus einer Spezifikation löschen konnte, es sei denn die gerade eben zuletzt eingegebene Zeile.
Die Spezifikationen wiesen in der Regel zwischen 30 und 50 Positionen auf und es kam schon einmal vor, dass man das gleiche Objektiv auf zwei verschiedenen Seiten fand.
Das Performance-Problem war einfach, dass der Suchvorgang pro Artikel 20 oder mehr Sekunden dauerte. Das klingt nicht so lange, vor allem dann nicht, wenn es sich um eine Web-Anwendung handelte. Aber das gab es damals noch nicht. Das war eine Standalone-Lösung. Mich trieb das jeweilige Warten in den Wahnsinn.
Auf meinem privaten Computer, den ich in die Firma gebracht hatte, – damals gab es noch keine PCs als Standardausrüstung – programmierte ich nach Dienstschluss mein eigenes Proforma-Programm. Ich hatte gerade Turbo-Pascal gelernt und wer diese Programmumgebung noch kennt, weiß, dass man damit teuflich schnell sein kann. Ich hatte das Glück, dass die Stammdatei-Artikel auf einer Diskette (170kB) untergebracht werden konnte. Und diese Stammdatei gab es auch immer, weil sie auf den Computer im Moskauer Büro überspielt werden mußte.
Ich wusste, was ich brauchte und konnte es mir im Notfall auch dazuprogrammieren. Mein Artikelsuchvorgang dauerte weniger als eine Sekunde, Bearbeitung, Nachbearbeitung, Aufsplittung einer Messe-Proforma in mehrere Angebote war kein Problem. Programm und Daten fanden auf zwei Disketten Platz. Ich wusste normalerweise nicht, auf welchem Rechner ich es laufen lassen musste. Manchmal war es ein Olivetti, dann wieder ein IBM-PC. (Die Rechner gehörten zu den ausgestellten Bildanalysegeräten.) Egal, das Programm lief überall.
Später lief es auch auf dem Moskauer PC. Es half mir, Spezifikationen innerhalb einer Nacht zu überarbeiten. Der Umsatz in meinem Geschäftsgebiet hatte sich in drei Jahren verdreifacht.
Ein Tester, den man auf das Programm angesetzt hätte, hätte feststellen können, dass das Programm langsam ist. Er hätte auch moniert, dass es fehlerintolerant war. Eine kleine Nachlässigkeit – und schon waren 30 Minuten Arbeit beim Teufel.
Doch in Wirklichkeit hätte man das alles bereits in der Analyse- und Designphase feststellen können. Damals zog das Argument: der Computer kann das nicht anders. Ich habe mir daher mit dem Gegenbeweis nicht nur Freunde gemacht. Aber ich sage: – und das besonders heute – Der Computer kann das, was wir von ihm fordern.
———————————————————————–
Der Titel dieses Blogs kann genau so sehr in die Irre führen wie der Gegenstand dieses Blogs. Ohne es genau zu hinterfragen, könnte man implizieren, dass der Autor 37 Jahre alt ist und damit rechnet, bis zu seinem 74 Lebensjahr arbeiten zu müssen. Wahr ist vielmehr, dass der Autor vor 37 Jahren das erste Mal mit einem Software-Fehler konfrontiert war. Irgendwo hat das dann in meinem Leben Niederschlag gefunden.
Das Thema dieses Blogs ist Software-Test.
Zum Einstieg möchte ich meine erste Begegnung mit einem Softwarefehler vor 37 Jahren berichten.
Als neunzehnjähriger Werkstudent arbeitete ich bei einem großen Elektronikkonzern in der EDV als Operator. Das war für mich die beste Gelegenheit, einem Computer nahe zu kommen.
Jeden Monat musste ein Programm laufen, dass sich „offene-Posten-Buchhaltung“ nannte. Es lief im Durchschnitt acht Stunden und war für den Operator ein angenehmes Programm. Zu Beginn musste man ungefähr einen Drittelmeter Lochkarten in die Zuführungsrinne platzieren. Danach lief das Programm von selbst mit Ausnahme der halbstündigen Bandwechsel im klimatisierten Bandraum.
Dann gab es noch einen notwendigen Eingriff. Nach einigen Stunden lief das Programm auf einen absoluten Halt. Die Daten mussten sortiert werden und der Sortiergenerator lief mit den vier Bandlaufwerken einfach nicht fehlerfrei. Es gab damals nur eine gleichartige Anlage, die sechs Laufwerke hatte. Dort war der Sort-und-Merge-Algorithmus entwickelt worden und hatte funktioniert. Ich erfuhr davon erst Jahre später.
Um das Programm fortzuführen, musste ich auf der Konsole einige Register neu laden. Die eingestellten Ziffern wurden mit kleinen Lämpchen im Excess-3-Code dargestellt. Danach wurde noch ein Sprungbefehl auf eine fixe Adresse eingegeben und auf RUN gedrückt. Nach einiger Zeit beherrschte man die Abfolge im Schlaf. Ich kann mich aber erinnern, dass ich ungläubig staunte, als ich meine Kollegen das erste Mal bei dieser Tätigkeit beobachtete.
Ich habe damals nicht verstanden, warum die Firma diesen Fehler nicht beheben ließ. Mir erschien es als sehr großes Sicherheitsrisiko, Menschen in den Ablauf eingreifen zu lassen. Weiß Gott, was man damals hätte hacken können:)
Heute darf ich behaupten, dass ich verstehe, warum man nichts unternommen hat. Das Leben mit Fehlern ist im Softwarebereich notwendig. Vernünftiger Software-Test sorgt aber dafür, dass wir unter den Fehlern nicht zu sehr leiden müssen und dass ihre Auswirkungen erträglich bleiben.
In diesem Blog möchte ich einige Gedanken darstellen, welche dieser Sorge Rechnung tragen.
Andreas Vitasek spielt im Film Und ewig schweigen die Männer einen 51-Jährigen, der mit seinem Alter nicht fertig wird.
Wie albern.
Auf twoday gibt es jedes Jahr zwei bis drei Blogs, in denen der Verlust des Lebens beklagt wird, weil der 40. Geburtstag zum Feiern ansteht.
Wie albern.
Auf twoday gibt es jedes Jahr zwei bis drei Blogs, in denen über die alten Männer hergezogen wird. Wie sie sich schleimig an die jungen Mädchen heranmachen.
Wie albern.
Das ist das Blog eines Neununddreißigers mit der Erfahrung eines Greises.
Auch albern.
–
Aber lustig!
Die meisten werden die obige Zahl als 19 identifizieren können, obwohl ich mir da bei der heutigen Jugend im allgemeinen nicht mehr so sicher bin. Das liegt nicht an der Jugend sondern an den Leuten, die Lateinunterricht abschaffen wollen, die Mathematikunterricht abschaffen wollen, die prinzipiell alles abschaffen wollen, wozu der Mensch Hirn braucht.
In Wien waren die Straßenschilder oft mit römischen Ziffern ausgewiesen. Die 19 konnte ich schon als kleines Kind lesen, da wir in diesem Bezirk gewohnt haben.
Schon damals hat mich fasziniert, dass in die Schreibweise einer Zahl die Subtraktion eingeflossen ist. 19 liegt näher an 20 und kann daher leichter durch die syntaktische Umstellung der Ziffern ausgedrückt werden.
XIX ist kürzer als XVIIII. Auf manchen historischen Gedenksteinen sieht man auch die Langform.
Für heute möchte ich es einmal stehen lassen, dass 9 eine besondere Zahl ist. Bei uns ist sie keine Unglückszahl wie z.B. in China, sondern eher eine Betrugszahl. 49.99 ist wirklich sehr viel näher an 50 als an 40, wie es uns die Preisgestalter glauben machen wollen.
Und es funktioniert. Selbst wenn man den Mechanismus durchschaut. Mathematisch ist es ja auch richtig. Doch dass sich auch unsere Gefühlswelt davon so täuschen lässt, überrascht mich immer noch.
Das ist eine Wiener Redewendung, die besagen soll, dass sich niemand zu sicher fühlen soll.
In den letzten Tagen wurden auch in diesem Medium einige Todesfälle vermeldet. Doch um diese geht es mir hier gar nicht.
–
Die Menschen fühlen sich recht sicher heutzutage. Es wird ein bisschen gejammert, es wird ein bisschen mitgefühlt. Und es wird ein bisschen Nachhaltigkeit vernachlässigt.
–
Nein, ich spreche jetzt nicht von dem Ölunglück im Golf von Mexico, obwohl sich das ja schon sehr gut anbieten würde. Ich spreche auch nicht von dem Zugunglück mit gerissenem „Bremsseil“ (bei Nömix nachzulesen), bei dem ich mich wundere, ob es überhaupt noch Menschen gibt, die mit einem deutschen Begriff auch die richtige Sache verbinden.
–
Jene (Quellen sind bekannt) an den Deutschkenntnissen aufgehängte Ausländerhatz scheint zu übersehen, dass wir Österreicher selber ja offensichtlich auch kein Deutsch mehr können. In Wirklichkeit geht es zum Beispiel um die Verwechslung von Ziehen und Drücken. Ich stelle es mir herrlich vor, wenn jeder Österreich-Leser bei einer Tür die angegebenen Begriffe verwechselt und unweigerlich mit dem Kopf anrennt. Das ist offensichtlich schon passiert, die Österreich-Leser und Österreich-Journalisten machen ja einen hinreichend „ang’rennten“ Eindruck.
–
Aber es sind nicht wir Österreicher allein. So einfach ist es nicht.
Es sind die Engländer (mit ihrem martialischen Sun-Journalismus, bei dem man sich ins Jahr 1939 zurückversetzt glaubt) und die Franzosen und die Italiener, die es uns vorzeigen.
Die Engländer haben es ja gerade noch geschafft. Bei den Franzosen und Italienern fragt man sich, wie schnell Fussballspieler das Spielen verlernen können. In Italien gab es bereits vor der WM Korruptionsskandale, über die eigenartigerweise niemand mehr spricht. Bei den Franzosen fangen die Skandale erst an.
Dass die Mannschaften ausgeschieden sind, ist noch nicht so schlimm, das ist weitaus engagierteren Mannschaften passiert. Aber die beobachtbare Lethargie bei Spielern, die um zweistellige Millionenbeträge gehandelt werden, ist schon beachtenswert.
–
Irgendwie stimmt das alles nicht zusammen. Unzählige gelbe Karten (Verwarnungen), kaum Tore und im wesentlichen langsamer Fussball. Und dabei ist Fussball etwas, was „jeden“ interessiert. Die Weltmeisterschaft ist neben den olympischen Spielen wohl die effizienteste Inszenierung von „circenses“, den Nachfolgern der Gladiatorkämpfen, mit denen man das „miese Volk“ davon abhält, sich gegen schlechte Regierungen zu erheben.
–
Lethargie macht sich breit. Und diese Lethargie wirkt nun bereits einlullenderweise auf alles, was rund um uns herum vorgeht.
–
Bei den Bloggern geht mir diese Lethargie erfreulicherweise ab. Es gibt nur zu wenige. Deswegen habe ich mich halt noch einmal dazugesellt.
Meine Erwartungshaltung an die Blogger drücke ich heute allerdings präziser aus:
Ich will nichts über die Lebensumstände und Befindlichkeiten lesen. Ich will angeregt werden und ich will über Schönes lesen. ich will über Menschen lesen, die sich an Dingen freuen können und diese Freude auch an andere Menschen vermitteln können.
Es gibt kein Leben ohne Trauer.
Aber bitte im Verhältnis 1:3…
einmal Trauer,
dreimal Freude.
So möchte ich meine Bestellung verstanden wissen. Doch wer von den Bloggern hört schon auf Bestellungen:)
Ich mag Berlin. Nicht nur, weil dort die U- und S-Bahnen auch in der Nacht fahren. Nicht nur, weil man in der Oranjenstraße auch noch um vier Uhr früh noch sehr dezent essen kann. Nicht nur, weil es das A-Train hat. (Jazz-Lokal)
Nicht nur, weil ich in der Jugend mit Nesthäkchen-Lektüre groß geworden bin.
Und auch nicht, weil es die Berliner Philharmoniker gibt. Die gibt es ja auch in Wien, nur heißen sie dort anders. Wir haben in Wien den Goldenen Saal, bei dem sich die Tontechniker der ganzen Welt fragen, wie man die Akustik noch einmal so gestalten kann.
Die Berliner haben die größte Bühne. Vielleicht nicht gemessen am Park Concert in New York. Doch 20.000 begeisterte Zuhörer in der Waldbühne ist schon ein Superlativ für sich.
Und neben der verschobenen Schweizreise, die sich heuer vielleicht nicht mehr ausgehen wird, plane ich ein nächstes Event, den Besuch eines Berliner Philharmoniker Abschlusskonzerts. Das muss ich mir einfach einmal geben.
Heuer war Renee Fleming der singende Star. Ich mag die Frau sehr. So sympathisch. Und singen kann sie auch.
In der Zugabe hat sie dann noch „O Mio Babbino Caro“ von Puccini gesungen.
Auf youtube gibt es auch Beispiele von ihr, doch als kleine Überraschung zitiere ich hier eine andere Sängerin, von der ich noch nie gehört habe. Sie ist halt in einem anderen Land berühmt.
Und singt auch sehr schön:)
Das ein Videobeweis das Spielergebnis erst am nächsten Tag ermöglicht, ist eine dumme Aussage, die ich FIFA-Funktionären zubillige. (Da gibt es ja mittlerweile sogar einen UEFA-Funktionär, der unter Bestechungsverdacht steht. UEFA ist nicht FIFA, aber warum sollten die besser sein?)
Dass ein Videobeweis das Spiel nicht über Gebühr aufhalten muss, kann man am amerikanischen Football sehen. Da bedarf es einer Anforderung von seiten der Mannschaft, die ihn fordert. Dann wird das Video angesehen und danach beurteilt.
Die Anzahl dieser Anforderungen ist beschränkt. Das wäre auch beim Fussball möglich, denn so viele derartige Situationen gibt es ja nicht in einem Spiel.
Aber wenn man schon so gegen elektronische Medien beim Spiel ist, dann sollte auch die Fernsehübertragung verboten werden, denn die nimmt den Spiel auch seinen Reiz.
Dabei sein, die Ausdünstungen des Nachbarn mitbekommen, das Bier über den Kopf geschüttet bekommen, Rempeleien um den Platz und lautstarke Beschimpfungen rund herum, das ist echter Fussball. Nicht auf der Couch vor dem Fernsehen sitzen und an kleinen Nüßchen knabbern.
Es gibt allerdings einen realen Grund, warum die Herrschaften den Videobeweis nicht zulassen wollen. Die fallweisen Ungerechtigkeiten sind erwünscht. Dann regen sich die Menschen auf, haben tagelang etwas zu diskutieren und werden von den eigentlichen Problemen abgelenkt. Wir haben ja auch keine wirklichen Probleme, oder?
Das hat schon seit 2000 Jahren so funktioniert oder länger.
Panem et circenses. Es war ja auch nicht gerecht, dass ein paar Gladiatoren über die Klinge springen musten.
Daher ist alles, was das Spiel objektiviert, verpönt. Blut wollen wir sehen, gemeine Fouls (Tore sind ja selten geworden) und Ungerechtigkeiten.
Dann dürfen wir uns selbst gut vorkommen.
(Sorry, wenn ich da vielleicht jemanden ans Bein pinkle.)
–
Ich habe den obigen Kommentar bei carpe diem abgelassen, weil sich dort ein paar Leute gegen Videobeweise im Fussball ausgesprochen haben.
Ich gebe ihnen damit ja recht.
–
Und ich behaupte einfach, dass eine Fehlentscheidung bei der Toranerkennung „peanuts“ ist, wenn man sie mit den Fehlentscheidungen in der Sicherheitstechnik vergleicht, die bei der BP-Bohrung passiert sind, wo nachweisliche Mängel keinen Aufruhr von Millionen von Menschen erzeugen. Oder zumindest nicht rechtzeitig.
Jänner 2018
Letzte Kommentare
Das 37. Jahr 