From: mkottenhahn@gmx.net (Mickey Kottenhahn)
Subject: Re: Disqualifikation
Date: Thu, 03 Jun 1999 13:56:46 +0200

Am Sun, 16 May 1999 22:47:32 +0200 verfaßte Knut König den Artikel
<373F2EE4.628FBEE2@rcs.urz.tu-dresden.de>:

[Bill Gates und sein Heim-Rechner]
>> Obwohl ich ja doch meine Zweifel hege, daß ein Mensch, der es sich
>> leisten kann, wirklich auf einem M$-basierenden Rechner zu arbeiten
>> nötig hat.
>> 
>Klar, woher wuerden sonst seine Untergebenen die vielen felherhaften
>Zielsetzungen ueber Weichzeug herbekommen?

Nun, nach all dem, was ich aus meiner Leküre von news:alt.fan.bill-gates
extrapolieren kann und zT mit inverser Logik in korrekte Aussagen
wandeln kann, ist doch anzunehmen, daß er folgende Strategie anwendet:

1. Wie läuft ein bestimmtes Feature auf _seinem_ Rechner.
2. er überlegt sich, wie dieses Feature noch optimiert werden könnte.
   Abhängig davon, ob eine weitere Optimierung zu gegebenem Zeitpunkt
   gerade möglich scheint, gibt es dann zwei Strategien:
3.
   a. Ist eine weitere Optimierung möglich, wird diese als eigene
      Zielsetzung definiert.
   b. Ist keine Optimierung möglich, dann wird halt eine erfunden und
      als eigene Zielsetzung definiert.
4. Die eigene Zielsetzung wird in zwei Elemente aufgeteilt:
   a. Die Feature-Elemente, welche auf einem M$-basierten System
      felherfrei implemtierbar sind. Hierzu zählen elementare Funktionen
      wie 1+1, Dateilöschoperationen und die Nichtbehebung von
       Dateisystemfehlern.
   b. Die Features-Elemente, bei denen eine M$-Implementation nicht von
      einem Grundschüler oder einem Programmierer ähnlichem Niveaus
      problemlos nachvollziehbar werden können.
5. Aus diesen beiden Featureteilen wird dann der Zielsetzungskatalog
   nach folgendem Schema erstellt: Man nehme die Elemente aus 4a.,
   streiche diese aus dem Zielsetzungskatalog heraus, nehme von 4b.
   willkürklich ungefähr die Hälfte heraus, die man als Zielsetzung an
   die Programmierer weiterreicht, wobei es vom Zufall abhängt, ob diese
   die Ziele tatsächlich implementieren können. Aus der anderen Hälfte
   erstelle man eine Invers-Liste und erhält dadurch einige Ziele, die
   *nicht* erreicht werden wollen, in der Hoffnung, daß durch Zufall
   auch wirklich einige Feature-Elemente richtig implementiert werden.
   Dadurch erhält der unbedarfte Anwender dann das Gefühl, ein
   'funktionierendes' Feature zu erhalten.

Und siehe da: Die Korrektheitsmenge der Features aka "formerly known as
bug" entspricht tatsächlich obiger Entscheidungsfindungsstrategie.



(Markus) Mickey Kottenhahn
-- 
___Mein_Platz_im_Netz_______________________________Die_Realität[tm]___
-> http://home.pages.de/~mickeyk/  <->  http://www.detebe.de/mickey/ <-
       Ich habe mich inzwischen über Teletubbies informiert. Ich finde,
 Horrorfilme am frühen Morgen sollten verboten werden. (Didi in detebe)

Zurück Einführung Übersicht Weiter