2017-05-11 digital life Faule Programmierer Was sind die Ursachen? Viele gute Programmierer fuehren Faulheit als eine herausragende ihrer Eigenschaften an. Faulheit wird gemeinhin negativ angesehen. Die Faulheit der guten Programmierer ist aber von po- sitiver Qualitaet. Sie gipfelt in Doug McIlroys Worten: As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow. Faule Programmierer wollen keine Bugs fixen muessen, also schreiben sie hochwertigen Code. Faule Programmierer wollen nicht muehsam Bugs jagen muessen, darum verbessern sie die Debugbarkeit ihrer Systeme. Faule Programmierer wollen keine stupide Arbeit von Hand machen muessen, darum bauen sie sich Helferlein. Faule Programmierer wollen nicht daran denken muessen, statische Information zu aktualisieren, deshalb wandeln sie sie in dynam- ische, stets aktuelle Information um. Faule Programmierer haben wenig Lust, Code oder Software immer wieder neu verstehen oder erklaeren zu muessen, darum reduzieren sie die Komplexitaet und erhoehen die Selbstdokumentation. Jetzt soll noch jemand sagen, dass die Faulheit (der guten Pro- grammierer) negativ sei! Was faule Programmierer am meisten hassen sind vermeidbare Prob- leme, weil diese unnoetige Arbeit verursachen. Da faule Program- mierer in ihrer Arbeit mit grossem Fleiss vermeidbare Probleme reduzieren, sind die meisten vermeidbaren Probleme, mit denen sie konfrontiert sind, durch Andere verursacht. Aus sozialen Gruenden und um den Frieden zu wahren, helfen sie aber mit das Problem zu fixen, und um das nicht nochmal tun zu muessen weisen sie darauf hin, was der tatsaechliche Grund fuer das Problem ist: naemlich, dass das System nicht so angelegt ist, dass das Problem vermieden wird. Schaut man in Abfallwirtschaftsgesetze, dann findet man dort stets klar (und mahnend) dargelegt, dass das oberste Ziel die Vermeidung von Abfall sein muss. So muss auch in der Informatik das oberste Ziel die Vermeidung von Bugs und unnoetiger Arbeit sein. Was aber wenn man uneinsichtig ist was das Vermeiden von Problemen betrifft? Natuerlich ist der Knackpunkt, dass die tatsaechliche Problemursache, also die schlechte Ausgestaltung des Systems, und folglich die tatsaechliche Problemloesung, naem- lich die Umgestaltung des Systems in eine Form, in der das Prob- lem nicht mehr auftreten kann, erkannt werden muss. Ich habe mal eine Kugelmuehle besichtigt. Dort werden Steinkugeln hergestellt: Man nimmt ein grob rundes Steinstueck, legt es in ein spezielles Muehlrad und wartet bis es vollkommen rund und glatt geschliffen ist. Relevant ist die Herstellung der grob run- den Rohlinge aus einem grossen Steinblock. Frueher hat man Wuer- fel gesaegt und bei denen von Hand die Ecken abgesaegt. Diese Saegerei sorgte fuer viele Unfaelle weil Hand und Saegeblatt eng beieinander sind. Man haette daraufhin sagen koennen, dass die Arbeiter halt gut aufpassen muessen -- das ist der allzu haeufige Fall. Man haette auch weitere Schutzsysteme einfuehren koennen, die die Arbeit zugunsten von mehr Sicherheit, erschweren -- eben- falls ein uebliches Vorgehen. Der Koenigsweg aber, den diese eine Kugelmuehle eingeschlagen hat, ist das Umstellen des Verfahrens, so dass keine Gefahrensituation mehr auftritt. Im konkreten Fall wurden Kernbohrer verwendet, um nicht Wuerfel sondern Zylinder als Rohlinge zu erzeugen. Diese sind von Haus aus runder als Wuerfel und das Absaegen der Ecken konnte eliminiert werden. Die etwas schlechtere Materialausbeute war erstens kein wirkliches Problem, auch weil genug Material guenstig zu bekommen war, und zweitens werden die durchloecherten Steine jetzt als Dekomaterial zusaetzlich verkauft. Es ist nun also nicht nur das Ursprungsproblem vermieden worden, sondern es wurden nebenbei auch noch zusaetzliche Vorteile gewonnen. Warum verbessert man dann nicht immer die Methoden? Das liegt daran, dass es besonders schwierig ist, bessere Methoden zu fin- den. Das heisst aber nicht, dass der Versuch nicht unternommen werden sollte. Ob man das tut oder nicht, das unterscheidet schliesslich die innovativen von den traegen Unternehmen. In manchen Faellen gibt es sogar schon jemanden, der die struk- turelle Problemvermeidung sieht ... er wird nur nicht gehoert oder sein Vorschlag wird ignoriert. ... aber spaeter soll er dann wieder die unnoetigen Folgeprobleme richten. Uns fehlt eine Kultur der (Technik-)Folgenabschaetzung! Auch die strukturelle Qualitaet von Umsetzungen wird kaum beachtet, er- kannt, oder gar bewertet. http://marmaro.de/apov/ markus schnalke