0x1b - ESCAPE
HTML PDF Postscript
 BWC vs. KISS 
Computer Geschrieben von Beat Rubischon (Link) am Dienstag, 11. August 2009, 08:31
aus dem *persönlichkeitsentwicklung* dept.

Bei den Computerleuten findet man zwei Richtungen: Die einen machen alles, Because we can. Und die anderen halten sich an den Grundsatz Keep it simple stupid.

Ich gehöre mittlerweile zur zweiten Gruppe. Wenn irgend möglich versuche ich Dinge so einfach wie möglich zu lösen, lasse weg, optimiere, indem ich es einfacher mache, Komplexität reduziere. Dabei bediene ich mich an einem Erfahrungsschatz von fast 25 Jahren because we can. Aber hey, das was früher war verschweigen wir doch einfach besser einmal :-)

Oft ärgere ich mich über komplexe Systeme. Sie haben den Hang zu komplexen Problemen, die Abhängigkeiten zwischen einzelnen Rechnern oder Services sorgen oft für unnötig viel Arbeit und Aerger. Und meist funktionieren sie dann nicht, wenn der Urheber der Lösung nicht greifbar ist. Es sind die Momente, in denen mir bewusst wird, dass Einfachheit durchaus ihre Vorteile hat.

Ein wunderbares Beispiel aus der Raumfahrt - mir kommt das eben in den Sinn, weil ich meinen langjährigen Begleiter, einen Parker Kugelschreiber, im Chaos der letzten Woche verloren habe. Astronauten sollten in der Lage sein, Notizen zu schreiben. Auch sie sind nur Menschen und vergessen Details. Dummerweise funktionierten die in den 50ern vorhandenen Kugelschreiber nicht in der Schwerelosigkeit. Also gab die NASA den Auftrag heraus, einen Kugelschreiber zu entwickeln, der in jeder Lage schreiben kann. Die Geschichte sagt, Parker soll ihn entwickelt haben. Noch lange machten sie Werbung dafür, dass man auch kopfüber mit einem solchen Kuli kritzeln kann. Auch dieser Kugelschreiber dürfte eines der Teile gewesen sein, dass nach dem Brand der posthum Apollo 1 genannten Kapsel einen detaillierten Bericht über die Verwendung von brennbaren Materialien und einen grundlegenden Designwandel durchgemacht hat. Und was machten die Russen? Sie gaben ihren Kosmonauten Bleistifte.

Aber es gibt auch eine andere Seite. Dummerweise kann man nur lernen, indem man Fehler macht. Dinge ausprobiert, neue Denkansätze versucht. Erfahrung kann man leider nicht lernen, auch wenn die IT Verantwortlichen oder Informatiklehrer heutzutage eben genau dieses erwarten. Da werden Rezepte vermittelt, Regeln aufgestellt. Meist sehr fragwürdige Lösungen. Experimentieren liegt nicht drinn, Erfahrungen sammeln ist unmöglich. Alles soll berechenbar sein, die Kosten so tief wie möglich gehalten werden.

Ein schönes Beispiel aus einer Mailingliste: Vor kurzem tauchte die Frage nach Firewalling auf. Die Regeln von der Schule heissen Zwiebelschalen, "rot", "gelb" und "grün". Von "grün" nach "gelb" und von "gelb" nach "rot" ist OK, die Gegenrichtung gesperrt. Ich habe durchaus solche Setups gebaut. Irgendwann kommt der Moment, wo ein Ding in "grün" von "rot" aus erreichbar sein muss. Beispielsweise der elende Exchange Server - steht er in "gelb", geht er nicht, steht er in "grün", muss ein Loch von "rot" gebrannt werden. Und *schwupps* ist das ganze Konzept für die Tonne. Oder dann werden Leute in "rot" mit einem Tunnnel ins "grün" verbunden. Das Zauberwort VPN steht für Sicherheit - was sich dahinter verbirgt, wird meist gar nicht erkannt.

Oder die aktuelle "goldene Regel" vom Virtualisieren. Die Marketingleute versprechen Kostenreduktion, Vereinfachung der Administration, bessere Ausnutzung der Ressourcen. Die Leute machen es, geben viel Geld aus für VmWare Lizenzen und neue Hardware, bekommen einen Komplexitätslayer mehr zum Administrieren und brauchen eine Serverfarm wie auch eine grosse Storage um ihr Ziel zu realisieren. Ich kann meine Mails nicht abrufen. Ist jetzt eines der 23 VLANs tot oder verkonfiguriert, ESX gecrasht, die Storage am Husten oder schlicht das Outlook im offline Modus? Nur durchdachte Virtualisierung bringt einen ans Ziel. Manchmal, ich behaupte immer, ist weniger mehr. Einfach drauflosvirtualisieren, weil man es so macht, führt zwangsläufig zum Desaster.

Am letzten Tag der diesjährigen International Supercomputing in Hamburg sprach der Chef des Grids vom CERN. Er sprach über die immense Menge Code, die entwickelt wurde und die vielen Probleme, die eben diese Codebasis bietet. Er ist sich voll bewusst, dass die Leute mit der Entwicklung dieser Software im Prinzip eine Sackgasse gewählt haben. Anstatt sie dafür zu verdammen, sah er darin einen Lernprozess, der allen Beteiligten einen grossen Erfahrungsschatz gegeben hat. Er behauptet gar, dass das Projekt ohne diese Erfahrung, ohne all diese Fehler, gar nicht machbar gewesen wäre. Niemand wusste im Voraus, wie sich ein Netz von über 100'000 Rechnern, verteilt über die ganze Welt, verhalten würde. Man musste es erst einmal bauen, um eine Idee davon zu bekommen, wie man es besser machen könnte.

Daher ein kleines Votum von mir: Lasst Eure Juniors Ideen entwickeln. Lasst sie Fehler machen. Motiviert sie, zuhause zu basteln und steht ihnen nicht im Wege, wenn sie Ideen in den Betrieb bringen. Ihr werdet Euch ärgern, manchmal mitten in der Nacht Probleme debuggen, die nicht sein müssten. Irgendwann werden sie ihren Erfahrungsschatz dazu verwenden, Dinge einfacher zu machen und die ideale Lösung einzusetzen. Nur so werden wir Nachwuchs haben, wenn wir alt und schrumplig auf unsere AHV warten.

Permalink

Das Kleingedruckte: Der Besitzer der folgenden Kommentare ist wer immer sie eingeschickt hat. Wir sind in keiner Weise für sie verantwortlich.

  • usul69@gmx.li Re: BWC vs. KISS
    Geschrieben von Usul (Link) am Dienstag, 11. August 2009, 13:43

    Das Problem, was ich manchmal da sehe: Es ist nicht einfach, den Einfluss von Erfahrung zu messen oder genau zu bestimmen. Wenn jemand ein Problem erfolgreich löst, hat er es dann mit Glück gelöst, weil gleich die erste von vielen Möglichkeiten die richtige war, oder war es wirklich sein Erfahrungsschatz? Sicher, im Laufe der Zeit bügelt die Statistik so Sachen wie Glück oder Zufall aus, aber bei einem singulären Ereignis ist es manchmal schwierig nachzuweisen, dass ein Problem aufgrund von Erfahrung gelöst wurde.

    Andersrum kann Erfahrung aber manchmal sogar ein wenig hinderlich sein ;) Jemand, der "schon alles gesehen hat", weiß viele Dinge, die schief gehen können und beugt entsprechend vor. Dann ist manchmal der Unbedarfte schlicht der Schnellere, weil er diverse Vorsichtsmaßnahmen nicht trifft - was natürlich nur so lange gut geht, wie nichts passiert. Trotzdem sieht der Erfahrene dann erstmal dumm aus, wenn er das gleiche Ergebnis erzielt, nur in längerer Zeit.

  • christof@buergi.lugs.ch Re: BWC vs. KISS
    Geschrieben von P2501 (Link) am Dienstag, 11. August 2009, 14:13

    Ja, das wurde mir auch gerade wieder bewusst. Kürzlich dachte ich mir: "He, diesen HTML-Filedialog könnte man doch auch mit AJAX machen." Natürlich habe ich bislang noch nie irgendwas mit AJAX gemacht, und Javascript-Toolkits sind nicht mein Fall. Also habe ich mich hingesetzt, Doku zusammengesucht, gebastelt, probiert, noch mehr Doku gesucht, weitergebastelt...

    Irgendwann hatte ich etwas, das funktionierte (und zwar in IE, FF und Safari). Natürlich war es jetzt ziemlich hässlicher Code, den ich nochmals sauber redesignen musste. Aber, und das ist das entscheidende: Ich wusste jetzt, wie!

    Nebenbei: Aus Neugier habe ich auch in Javascript-Toolkits reingeguckt, um zu sehen, ob sie auf die gleiche Lösung gekommen sind. Seither weiss ich, was für schmutzige, schmutzige Tricks diese Toolkits zuweilen einsetzen. ;-)

    • Re: BWC vs. KISS
      Geschrieben von Zimmi am Dienstag, 11. August 2009, 18:19

      Hi

      Bei diesem Eintrag kam mir der Spruch von Perl in den Sinn TIMTOWTDI (There's more than one way to do it).
      Ich gebe auch noch zu bedenken, dass ein Code welcher gut aussieht nicht unbedingt performant laufen muss.

      Gruss
      Zimmi

      • christof@buergi.lugs.ch Re: BWC vs. KISS
        Geschrieben von P2501 (Link) am Mittwoch, 12. August 2009, 09:41

        Nur zur Klarstellung: Wenn ich von schmutzigen Tricks spreche, meine ich wirklich schmutzige Tricks. Dinge wie den IE-DomContentLoaded Hack oder den Include Hack.

        • Re: BWC vs. KISS
          Geschrieben von Zimmi am Mittwoch, 12. August 2009, 10:24

          Sorry, meine zweite Aussage war allgemein gemeint.
          Wollte deine Aussage nicht relativieren.

  • Re: BWC vs. KISS
    Geschrieben von dsd am Freitag, 21. August 2009, 15:29

    "Der Mensch hat dreierlei Wege klug zu handeln: erstens durch nachdenken, das ist der edelste, zweitens durch nachahmen, das ist der leichteste, und drittens durch Erfahrung, das ist der bitterste."

    Ohne dem Inhalt des Artikels in seinen Grundzügen widersprechen zu wollen, möchte ich folgendes anfügen: Das Lehren von Regeln und Mustern ist die einzige Möglichkeit, wie wir unseren Nachkommen unsere eigene Erfahrung weitergeben können.

    Das Problem sind nicht die Regeln und Muster an sich, sondern einen falschen Bezug, den man als Schüler allenfalls zu ihnen hat. Anstatt die Muster und ihre Notwendigkeit zu verstehen, versucht man sie schlicht 1:1 in der Praxis anzuwenden. Das geht meistens schief.

    Was in der Lehre allerorts zu wenig praktiziert wird, ist einerseits Regeln und Muster zu studieren, aber andererseits auch das "Nachdenken" über diese Regeln und Muster zu fördern, bzw. den Schüler zu ermahnen, dass das Gelernte (Regeln, Muster, etc.) nur Hilfsmittel und keine Lösungen sind.



    • foo@porn.bar Re: BWC vs. KISS
      Geschrieben von Alain (Link) am Donnerstag, 10. September 2009, 07:33

      schöne, wahre worte! :)