[erledigt] Wieder pic: Kreislinien verbergen? ‒ und "Clean Agile"

[eggy]

@Meillo: Ja, das mit dem Buch hab ich mitbekommen. Deswegen ja auch meine Nachfrage, ob er auch die "Errata" behandelt.

Und auch wenn man ein Buch zusammenfasst, kann man ja trotzdem versuchen, es besser zu machen (zumal es in bei den Originalgrafiken vielleicht ja auch Probleme in Bezug aufs Urherberrecht geben könnte).
Ich hab versucht auszublenden, was ich zu der Thematik im Studium gehört hab und versucht "mit frischen Augen" auf die Grafik zu schauen ... und da ist, wie bei vielen dieser Schlagwortmodellbilder, eben nicht eindeutig klar, was mit dem Bild gesagt werden soll.
Jedenfalls mir nicht, kann ja gut sein, dass andere das anders sehen. Der Text hingegen wirkt auf mich gut strukturiert, beim Überfliegen hatte ich den Eindruck, "ok, da gibts Kategorien und die gleichzeitige Erfüllbarkeit ist nicht gegeben" ... diesen klaren Erkenntnis-Eindruck hab ich bei dem Bild eben nicht. Außerdem: der Text wird durch das Bild auch nicht verständlicher - und damit ist das Bild überflüssig. Und das trifft (ohne mich an das Buch erinnern zu können) vermutlich auch auf die Ring-Abbildung zu.

Ich hab mich beim Lesen von anderen Papern/Büchern halt schon öfter geärgert, wenn ich minutenlang auf eine Abbildung gestarrt hab, um den verborgenen Sinn darin zu finden und dann stellt sich raus, die Grafiken sind absolut überflüssig und vermutlich nur drin, damit ne gewisse Menge Seiten erreicht wird oder noch schlimmer, nur damit der umgebene Text "wissenschaftlich" aussieht.

@paedubucher: Meine Probleme mit dem "ganzen Modell" fangen aber schon viel früher an, nämlich bei der Annahme, dass man die Aufgaben überhaupt immer in gleichwertige Tasks zerlegen könnte.
Folglich passt die, von Dir in 3.1 zugrunde gelegte, Mathematik so nämlich nicht, Stichwort: "bedingte Wahrscheinlichkeiten". Die Prozente der simplen Tasks gleichen sich nämlich nicht über einen Zeitraum gegenseitig aus. In der Realität multiplizieren sie sich: mit jedem neuem kleinem Task wird es unwahrscheinlicher, dass nen Projekt überhaupt fertig wird.
Grundsätzlich bleibt's bei der Erkenntnis aus Frederick Brooks "the mythical man month": Eine Frau braucht neun Monate für ein Baby; neun Frauen dann also einen Monat - oops.

[paedubucher]

@paedubucher: Meine Probleme mit dem "ganzen Modell" fangen aber schon viel früher an, nämlich bei der Annahme, dass man die Aufgaben überhaupt immer in gleichwertige Tasks zerlegen könnte.
Folglich passt die, von Dir in 3.1 zugrunde gelegte, Mathematik so nämlich nicht, Stichwort: "bedingte Wahrscheinlichkeiten". Die Prozente der simplen Tasks gleichen sich nämlich nicht über einen Zeitraum gegenseitig aus. In der Realität multiplizieren sie sich: mit jedem neuem kleinem Task wird es unwahrscheinlicher, dass nen Projekt überhaupt fertig wird.
Grundsätzlich bleibt's bei der Erkenntnis aus Frederick Brooks "the mythical man month": Eine Frau braucht neun Monate für ein Baby; neun Frauen dann also einen Monat - oops.

Vielen herzlichen Dank für diese Einschätzung. Ich bin sehr froh darüber, dass ich nicht der einzige bin, der von dieser Methodik wenig hält. Man kann nicht schätzen, schätzt dann eben ungenau, in der Hoffnung, dass die Wahrheit im Unschärfebereich liegt. Der ganze Text ist auch dahingehend widersprüchlich, dass man später einfach mal anfängt zu entwickeln, und dann erst auf eine seriöse Einschätzung von Aufwand kommt. Dieses ganze Schätzen vorab ist deshalb völlig sinnlos. Mir scheint, dass hier den Leuten etwas an die Hand gegeben wird, die in ihrem Beruf dann doch zu einer Schätzung genötigt werden.

Dass sich die Unschärfe mit der Zeit augleicht, ist eine völlige Schönwetterannahme. Bei solchen Vorgängen gibt es eine Asymmetrie: Die Wahrscheinlichkeit an einer Aufgabe doppelt so lange zu haben ist wesentlich grösser, als nur halb so lange daran zu sitzen. (So ähnlich wie bei Interkontinentalflügen, wo man im besten Fall eine halbe Stunde früher, im schlechtesten Fall erst viele Stunden später da ist.)

Ich schätze diese Kritik sehr, gerade weil Boomer Bob sonst immer nur in den Himmel hoch gepriesen wird. Meine Zusammenfassung muss aber im Endeffekt das wiedergeben, was im Buch steht. Aber ich muss es nicht so an meine Schüler weitergeben.

[Meillo]

Das mit dem zweidimensionalen "Raum" funktioniert dann wirklich nicht mehr. Darum habe ich die beiden Achsen eingefügt. Gut oder billig, schnell fertig oder alles fertig; das sind schon die stärksten Gegensätze.

Diese ``staerksten Gegensaetze'' will ich so nicht akzeptieren. Die Aussage des Dreiecks ist IMO gerade, dass es drei in jeweils gleicher Weise von den anderen zwei abhaengende Faktoren gibt. Du bzw. das Iron Cross sagt nun, dass dem nicht so waere. Das ueberzeugt mich nicht und reduziert damit IMO gerade die wertvollste Aussage des Dreiecks.

Aus meiner Sicht ueberschneidet sich der Faktor Scope am staerksten mit dem Faktor Qualitaet, hat aber wenig mit Kosten oder Zeit zu tun. Genau genommen ist ja gerade dieser ganze agile Ansatz der Versuch das Scope-Problem in den Griff zu bekommen, waehrend man bei den anderen drei Faktoren weiterhin frei waehlen kann. Am Scope zu schrauben waere wie mehr oder weniger agil zu arbeiten.

Ueberhaupt finde ich diese Scope-Faktor als freie Entscheidungsachse seltsam. Fuer mich macht es Sinn, zu sagen, dass ich wenig Geld ausgeben will, oder in Kauf zu nehmen, dass es teuer wird. Fuer mich macht es auch Sinn, zu sagen, dass es schnell fertig sein soll, oder in Kauf zu nehmen, dass es laenger dauert. Fuer mich macht es auch Sinn, zu sagen, dass die Programmqualitaet hoch sein soll, oder in Kauf zu nehmen, dass manches nicht so gut funktioniert oder Folgekosten hoeher sind. Fuer mich macht es aber wenig Sinn, zu sagen, dass das Programm mein Problem loesen soll, oder in Kauf zu nehmen, dass es unpassend ist.

Gibt es im Buch denn eine Erklaerung, warum der Scope hinzugefuegt worden ist und warum er gleichwertig zu den anderen drei Faktoren angesehen wird?

[Meillo]

Außerdem: der Text wird durch das Bild auch nicht verständlicher - und damit ist das Bild überflüssig. Und das trifft (ohne mich an das Buch erinnern zu können) vermutlich auch auf die Ring-Abbildung zu.

So denke ich auch ... Aber: Ich habe gelernt, dass fuer manche das Optische/Grafische enorm wichtig ist, um Informationen aufzunehmen. Es ist fuer diesen Zweck nicht so wichtig wie genau die Grafik aussieht oder wie korrekt sie ist, sie koennen sich die Dinge dann trotzdem besser merken oder auch ueberhaupt nur aufmerksam bleiben. Mir sind andere Dinge wichtiger aber das trifft nicht auf jeden gleichermassen zu. Darum wuerde ich sagen, dass die Abbildung *nicht* ueberfluessig ist (auch wenn sie es rein inhaltlich womoeglich doch ist). Besser waere es allerdings eine wirklich passende und wertschoepfende Grafik einzufuegen ... das ist halt eine Qualitaetsfrage ... und da liegen im Clean-Code-Umfeld IMO die Prioritaeten halt leider eher bei Zeit und Geld.

[paedubucher]

Das mit dem zweidimensionalen "Raum" funktioniert dann wirklich nicht mehr. Darum habe ich die beiden Achsen eingefügt. Gut oder billig, schnell fertig oder alles fertig; das sind schon die stärksten Gegensätze.

Diese ``staerksten Gegensaetze'' will ich so nicht akzeptieren. Die Aussage des Dreiecks ist IMO gerade, dass es drei in jeweils gleicher Weise von den anderen zwei abhaengende Faktoren gibt. Du bzw. das Iron Cross sagt nun, dass dem nicht so waere. Das ueberzeugt mich nicht und reduziert damit IMO gerade die wertvollste Aussage des Dreiecks.

Im Endeffekt reduziert das "Iron Cross" die Darstellung auf die beiden Achsen Qualität (X) und Quantität (Y). Gut oder günstig; viel vornehmen oder fertig werden. Das ist ein Rückschritt gegenüber dem Dreieck, das mit drei Variablen operiert. Aber diesen Rückschritt kommt mit den beiden dargestellten Achse auch zum Ausdruck.

Aus meiner Sicht ueberschneidet sich der Faktor Scope am staerksten mit dem Faktor Qualitaet, hat aber wenig mit Kosten oder Zeit zu tun. Genau genommen ist ja gerade dieser ganze agile Ansatz der Versuch das Scope-Problem in den Griff zu bekommen, waehrend man bei den anderen drei Faktoren weiterhin frei waehlen kann. Am Scope zu schrauben waere wie mehr oder weniger agil zu arbeiten.

Ueberhaupt finde ich diese Scope-Faktor als freie Entscheidungsachse seltsam. Fuer mich macht es Sinn, zu sagen, dass ich wenig Geld ausgeben will, oder in Kauf zu nehmen, dass es teuer wird. Fuer mich macht es auch Sinn, zu sagen, dass es schnell fertig sein soll, oder in Kauf zu nehmen, dass es laenger dauert. Fuer mich macht es auch Sinn, zu sagen, dass die Programmqualitaet hoch sein soll, oder in Kauf zu nehmen, dass manches nicht so gut funktioniert oder Folgekosten hoeher sind. Fuer mich macht es aber wenig Sinn, zu sagen, dass das Programm mein Problem loesen soll, oder in Kauf zu nehmen, dass es unpassend ist.

Fertig werden oder nicht ist ja im Grunde eine Frage des gewählten Scopes. Von daher wirkt diese vertikale Achse eben schon sehr gesucht auf mich. Wie gesagt: wir hatten eigentlich drei Variablen, jetzt wird noch eine vierte eingefügt. Vielleicht war das Dreieck nicht cool genug, und da musste eben etwas "krasseres" her: das eiserne Kreuz!

Gibt es im Buch denn eine Erklaerung, warum der Scope hinzugefuegt worden ist und warum er gleichwertig zu den anderen drei Faktoren angesehen wird?

Das werde ich gelegentlich nachlesen. Ich habe die Stelle gerade nicht mehr so präsent. Tatsächlich wird zunächst im Buch dieses Kreuz eingeführt, später wird es dann um die Steuerungsmassnahmen ergänzt. Ich bin jetzt schon länger an dieser Arbeit dran, schaffe vielleicht eine halbe bis eine Seite pro Tag. Dann verliere ich die Motivation.

Gegen hinten wird das Buch dann nervig. Zuerst meint der Autor etwa, dass Zertifizierungen für "Agile" (alleine der Begriff nervt mich mittlerweile) völliger Schwachsinn seien. OK, diese Meinung ist jetzt nicht so abwegig. Aber im gleichen Kapitel folgt ein Gastbeitrag von einem Autor, der seitenlang verschiedene Zertifizierungen empfiehlt. (Das gleiche dann noch mit Meta-Frameworks wie SAFE und LESS; Martin findet es unnötig, der Gastbeitrag preist es an.) So ein Buch von ca. 180 Seiten sollte schon so etwas wie eine Einheit haben.

Hätte ich doch einfach Weinberg genommen, da wäre etwas zu lernen gewesen. Ist halt leider nicht "agil" bzw. "Agile".

Was auch auf dem vorgegebenen Lehrplan steht: "Clean Code"

Ich glaube, ich erlaube mir da einen derben Witz, irgend etwas mit dem "Klean Kode Klan", der Brian Kernighan dafür lyncht, dass er in for (i = 0; i < n; i++) "wenig aussagekräftige Variablennamen" verwendet (kein Witz, hat mal ein Professor so kritisiert).

Außerdem: der Text wird durch das Bild auch nicht verständlicher - und damit ist das Bild überflüssig. Und das trifft (ohne mich an das Buch erinnern zu können) vermutlich auch auf die Ring-Abbildung zu.

So denke ich auch ... Aber: Ich habe gelernt, dass fuer manche das Optische/Grafische enorm wichtig ist, um Informationen aufzunehmen. Es ist fuer diesen Zweck nicht so wichtig wie genau die Grafik aussieht oder wie korrekt sie ist, sie koennen sich die Dinge dann trotzdem besser merken oder auch ueberhaupt nur aufmerksam bleiben. Mir sind andere Dinge wichtiger aber das trifft nicht auf jeden gleichermassen zu. Darum wuerde ich sagen, dass die Abbildung *nicht* ueberfluessig ist (auch wenn sie es rein inhaltlich womoeglich doch ist). Besser waere es allerdings eine wirklich passende und wertschoepfende Grafik einzufuegen ... das ist halt eine Qualitaetsfrage ... und da liegen im Clean-Code-Umfeld IMO die Prioritaeten halt leider eher bei Zeit und Geld.

Das ist auch der Grund, warum ich überhaupt Grafiken mache. Einerseits möchte ich natürlich pic lernen, was ja wirklich eine interessante Sache ist. Aber andererseits sind eben nicht alle Leute so textorientiert wie ich, sondern eher "visuelle Lerntypen" (gibt es das wirklich?). Dem will ich gerecht werden.

Nachtrag: ich zitiere (Clean Code, p. 15):

The reason that these techniques fail so spectacularly is that the managers who use them do not understand the fundamental physics of software projects. This physics constrains all projects to obey an unassailable trade-off called the Iron Cross of project management. Good, fast, cheap, done: Pick any three you like. You can't have the fourth. You can have a project that is good, fast, and cheap, but it won't get done. You can have a project that is done, cheap, and fast, but it won't be any good.

Hier klingt "done" fast schon wie "existiert in der Realität oder nur in der Fiktion". Weiter:

The reality is that a good project manager understands that these four attributes have coefficients. A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary (Hervorhebung paedubucher) [...]

Hier wird es geradezu lächerlich. Ich hätte es gerne erledigt, aber nur zu 72.5%.

Die ganze Kategorie "Done" ist somit, jedenfalls wie sie hier erklärt wird, kompletter Humbug.



"Look here, I'm full of shit!"

[Meillo]

Danke fuer den Nachtrag. Schon davor ist mir beim Lesen deines Post bewusst geworden, dass ich nicht verstanden habe, was mit ``Scope'' oder ``done'' gemeint ist. Ich dachte, ``Scope'' bedeutet ``Zielrichtung'', aber dann hatte ich langsam eher den Eindruck, es wuerde ``Umfang'' bedeuten. Den Begriff ``done'' verstehe ich noch weniger. Wenn es nicht fertig wird, dann macht es doch ueberhaupt keinen Sinn ... aber nicht fertig zu werden ist ja schon ueber die Zeitachse abgedeckt. Ich werde nur verwirrter.

Dann sagt er -- wie du schreibst --: you can't have all four of them. Und danach empfiehlt er doch von allen vieren ``genug'' zu nehmen. Ich gewinne daraus jedenfalls keine Weisheit. Nun schaue ich mir das ja nur ganz oberflaechlich ueber deine Beitraege hier an. Eigentlich sollte ich mir das Buch selber vornehmen, genau hinschauen und es in Ruhe durchdenken ... aber ehrlich gesagt habe ich schon vier Anlaeufe unternommen ``Clean Code'' zu lesen, aber jedes Mal nach den naechsten fuenfzehn Seiten gebe ich enttaeuscht auf, finde meine Zeit dafuer zu schade. Dann nehme ich mir ein Buch von Kernighan oder Weinberg zur Hand oder lese einen EWD ... und mein Geist weitet sich!


P.S. Vielleicht solltest du mutig sein und den Begriff ``Clean Code'' in deinem Lehrplan sinngemaess verstehen ... und deinen Schuelern zeigen wo man wirklich lernen kann was guter Code ist.

[paedubucher]

Danke fuer den Nachtrag. Schon davor ist mir beim Lesen deines Post bewusst geworden, dass ich nicht verstanden habe, was mit ``Scope'' oder ``done'' gemeint ist. Ich dachte, ``Scope'' bedeutet ``Zielrichtung'', aber dann hatte ich langsam eher den Eindruck, es wuerde ``Umfang'' bedeuten. Den Begriff ``done'' verstehe ich noch weniger. Wenn es nicht fertig wird, dann macht es doch ueberhaupt keinen Sinn ... aber nicht fertig zu werden ist ja schon ueber die Zeitachse abgedeckt. Ich werde nur verwirrter.

Ich habe zunächst darüber mehr oder weniger hinweggelesen. Ich erinnerte mich an das Dreieck, und fragte mich, wozu jetzt die weitere Variable gut sein soll. Aber da ich am zusammenfassen war, habe ich das einfach mal so wiedergegeben. Vielleicht sollte man das so lesen, und nicht etwa kritisch

Dann sagt er -- wie du schreibst --: you can't have all four of them. Und danach empfiehlt er doch von allen vieren ``genug'' zu nehmen. Ich gewinne daraus jedenfalls keine Weisheit. Nun schaue ich mir das ja nur ganz oberflaechlich ueber deine Beitraege hier an. Eigentlich sollte ich mir das Buch selber vornehmen, genau hinschauen und es in Ruhe durchdenken ... aber ehrlich gesagt habe ich schon vier Anlaeufe unternommen ``Clean Code'' zu lesen, aber jedes Mal nach den naechsten fuenfzehn Seiten gebe ich enttaeuscht auf, finde meine Zeit dafuer zu schade. Dann nehme ich mir ein Buch von Kernighan oder Weinberg zur Hand oder lese einen EWD ... und mein Geist weitet sich!

Hier geht es übrigens um "Clean Agile", nicht um "Clean Code". Es gibt noch "Clean Architecture" und "The Clean Coder". Im Herbst kommt dann noch "Clean Craftsmanship". Aber nach zwei Büchern erscheint mir jedes Weitere nur als Remix der vorherigen.
Bei "Clean Code" bin ich übrigens nie durchgekommen. Ist man erstmals von Java weg, sieht man, wie eingeschränkt die Perspektive dort ist.

P.S. Vielleicht solltest du mutig sein und den Begriff ``Clean Code'' in deinem Lehrplan sinngemaess verstehen ... und deinen Schuelern zeigen wo man wirklich lernen kann was guter Code ist.

Kernighan und Dijkstra oben sind gute Stichworte. "The Elements of Programming Style" kann ich sicherlich nicht direkt verwenden, aber was er in einem dazugehörigen Vortrag Jahre später brachte, ist perfektes Anschauungsmaterial!

[eggy]

[url=https://www.youtube.com/watch?v=8SUkrR7ZfTA]

Danke, das Video kannte ich noch nicht

Offtopic, aber auch sehenswert: https://www.youtube.com/watch?v=EY6q5dv_B-o (ab etwa 8:00 min)

[paedubucher]

[url=https://www.youtube.com/watch?v=8SUkrR7ZfTA]

Danke, das Video kannte ich noch nicht

Offtopic, aber auch sehenswert: https://www.youtube.com/watch?v=EY6q5dv_B-o (ab etwa 8:00 min)

Dieses Interview kannte ich schon, es ist aber wirklich grossartig. Es ist so schön zu sehen, wie solche gestandenen Profis völlig auf dem Boden geblieben sind. Das ist genau das Gegenteil dieser "Boomer"-Attitüde, die mich an Robert C. Martin so nervt.

[paedubucher]

Nachtrag zu Clean Code: Ich bin heute auf dieses sehr kritische Review gestossen.

[Meillo]

Nachtrag zu Clean Code: Ich bin heute auf dieses sehr kritische Review gestossen.

Ich finde es ja nett, wie dort sowas steht wie: Vielleicht sollten wir aufhoeren, ``Clean Code'' zu empfehlen. Ich glaube, dass diese Formulierung schon eine Menge aussagt. Sie zeigt naemlich, dass diese Empfehlungen nicht differenzierte, persoenliche Empfehlungen waren, sondern ein wenig differenziertes Massenphaenomen. Nun beginnt man dieses etablierte Standardverhalten (Clean Code ist super) zu hinterfragen.

Fuer mich bestaetigt das das Hauptproblem von Clean Code: Den (bewusst aufgebauten) Kultfaktor davon. Dieser fuehr naemlich genau zu so etwas. Dabei sollte das Buch, fuer das was es inhaltlich zu erreichen vorgibt, gerade das Gegenteil anstreben: Dass die Entwickler selber denken, eigenstaendig analysieren und reflektiert selber entscheiden. Taeten sie das, dann, glaube ich, wuerde man man nicht zu einem Punkt kommen, wo eine kollektive Aenderung im Empfehlungsverhalten noetig wird, weil es nie diese kollektive, normierte Empfehlung gegeben haette.

Nun wird in den Kommentaren x-fach Ousterhouts Buch genannt. Fuer mich ist dieses wie das vielleicht wertvollste Computerbuch der letzten Jahre erschienen. Ich dachte, dass das grossartig sein koennte (weil Tcl und Tk grossartig sind). Als ich einen Teil davon gelesen hatte, war ich nicht mehr so begeistert. Es steckt durchaus einiges Gutes darin (und ich habe es auch noch nicht ganz gelesen), aber beispielsweise seine Ansichten und Empfehlungen zu Kommentaren und Bezeichnern halte ich teilweise fuer schaedlich. Gleichzeitig kann ich gut verstehen warum gerade die vormaligen Clean Code Liebhaber dieses Buch gerne haben werden. Es geht von den Ansichten schon auch in die Richtung. Ich bin bislang eher enttaeuscht von ihm, weil es bei weitem nicht die Klarheit und IMO Sinnhaftigkeit hat, die ich mir erhofft haette.

Noch immer ist Kernighan und Pikes ``The Practice of Programming'' (das von 1999 ist; Clean Code ist von 2009) dasjenige Buch, das ich empfehle ... aber natuerlich ist es ohne OOP und ohne moderne Design-Patterns und ohne all das was sich moderne Entwickler fuer modernen Code wuenschen. Und ja, wenn man in so Projekten steckt, dann muss man auch die dafuer passenden Buecher lesen, um darin erfolgreich zu sein. Ich befinde mich hier eine Ebene hoeher (und so will ich die von paedubucher verlinkte Kritik auch ansehen): Ist das eine gute Art um Code zu entwickeln, oder sind wir auf einem Holzweg?


Insgesamt moechte ich meine Meinung so auf den Punkt bringen: Jedes Buch, das dazu motiviert, selbst zu denken, das uns Perspektiven eroeffnet und Fragen stellt, ohne Antworten vorzugeben, ist ein hilfreiches Buch. Jedes Buch, das uns sagt was wir tun sollen, steht wirklich gutem Code im Weg.