Ich halte das für einen sehr guten Artikel. Gerade solche Materialien mit solchen 'Zahlen' sind wertvoll. In einer Zeit, in der man nur schwer Entwickler findet, die auch nur ein ungefähres Gefühl dafür haben, welchen Overhead der von uns geschriebene Code und der von uns verwendete Tech-Stack mit sich bringen, habe ich den Text mit Freude gelesen.
Die Analogie scheint passend zu sein. Mein Projekt besteht de facto ebenfalls nur aus zwei Dingen: der menschlichen Intent und einem Snapshot.
Letztlich dachte ich, dass die Richtung, in die sich mein Projekt entwickeln sollte, darin besteht, zu berechnen, wie die menschliche Absicht (z. B. Tastatureingaben, Mausklicks) zu verstehen ist und welche Bedeutung sie erhalten soll.
Ich wollte gerade einen Beitrag dazu schreiben, nachdem ich die Veröffentlichung gesehen hatte, aber Sie haben ihn schon verfasst.
Ich bin gespannt, wie leistungsfähig es sein wird.
Das Konzept ist attraktiv, aber meiner Erfahrung nach waren solche idealistischen Versuche nur selten erfolgreich..
Bis jetzt scheint Feedly mit seinen AI-Funktionen immer noch am besten und insgesamt am unkompliziertesten zu sein.
Das ist der grundlegende Inhalt, der in den meisten Büchern über agile Methoden vorkommt, etwa Kent Becks Extreme Programming oder Jeff Sutherlands Scrum. Man kann sich auch User Stories ansehen. Die meisten Menschen wissen offenbar nicht genau, dass die Grundlage von Agile kurze Sprints und Demos sind, um sich schnell an Kundenanforderungen anzupassen.
Ich kann Ihrer Meinung gut nachvollziehen.
Es gibt eindeutig Bereiche, die sich nicht durch Code ersetzen lassen.
In diesem Sinne wollte ich es etwas anders ausdrücken: Gut lesbarer Code macht es möglich, dass man keine Dokumentation mehr erstellen muss.
Auch die Dokumentation, die sich im Lauf eines langlebigen Softwareprojekts ansammelt, erzeugt bei Entwicklerinnen und Entwicklern kognitive Belastung. Im Kern geht es darum, die Arbeit zu verringern, ständig zwischen Code und Dokumentation hin- und herzuschalten.
Ich denke nicht, dass am Ende ausschließlich Code übrig bleiben kann.
Ich denke, das kann je nach Kontext und Situation unterschiedlich sein.
Vielen Dank für Ihren Kommentar.
Um den Einwand vorsichtig zu formulieren: Ich denke nicht, dass Code Dokumentation ersetzen kann. Programmiersprachen verfügen noch nicht über die Ausdrucksstärke und Vermittlungskraft natürlicher Sprache, und ganz praktisch: Wer soll all diesen Code überhaupt komplett lesen?
Zu hoffen und sich zu wünschen, einmal Code zu haben, der Dokumentation ersetzen kann, ist wie der Turmbau zu Babel, den man nie vollenden wird.
Da erscheint es mir sinnvoller, sich lieber gründlich mit OOAD zu beschäftigen.
Was genau bedeutet es, die Spezifikation selbst agil zu schreiben?
Die Spezifikation wird grob hingeschrieben.
Die Spezifikation wird so geschrieben, wie der Kunde sie diktiert.
Wenn sich die Kundenanforderungen ändern, wird sie mithilfe von Tools so gepflegt, dass die Spezifikation schnell angepasst werden kann.
Die Spezifikation wird agil geschrieben.
Der Kern des Artikels ist doch von vornherein, dass man gar nicht weiß, was Agilität überhaupt ist. Es wurde immer nur darüber geredet, dass Agile diese und jene Eigenschaften habe und man dies und das tun müsse, aber einen Artikel, der tatsächlich zeigt: Das ist ein Produkt, das mit einer agilen Methodik entstanden ist, habe ich bis heute nicht gesehen. Selbst wenn man sich das Manifest ansieht, bleibt es irgendwie vage. Vielleicht könnten Sie einmal ein konkretes Beispiel zeigen.
Ich verstehe nicht, warum man Methodologien so sehr wie heilige Schriften behandelt. Ich finde, dass auch der ursprüngliche Autor zwar nur eine andere Ausrichtung hatte, aber letztlich genauso dogmatisch war.
Ab dem Moment, in dem man sich für SQLite auf einem Produktionsserver entscheidet, muss man sich ständig Gedanken darüber machen, wann man davon wegmigriert.
Früher lohnte sich diese Überlegung, weil die Kosten der DB selbst (Serveranschaffung, IDC, Lizenzkosten usw.) hoch waren,
aber heute lässt sich das Ganze sprichwörtlich per Klick aufsetzen – muss man dann wirklich noch darüber nachdenken?
Schon allein die Botschaften, die uns der Abbau vertikaler Entscheidungsstrukturen und die iterative Verbesserung in kurzen Zyklen hinterlassen, sind groß (natürlich gilt das ebenso für Projektmanagement-Methoden und -Tools).
Die Schlussfolgerung, dass „Agile selbst keine neuen Einsichten geliefert habe und die Gesamtheit der Menschen, die Agile befürworten, als blinde Agile-Fanatiker diffamiert“ werde, scheint mir etwas überzogen.
Ich halte das für einen sehr guten Artikel. Gerade solche Materialien mit solchen 'Zahlen' sind wertvoll. In einer Zeit, in der man nur schwer Entwickler findet, die auch nur ein ungefähres Gefühl dafür haben, welchen Overhead der von uns geschriebene Code und der von uns verwendete Tech-Stack mit sich bringen, habe ich den Text mit Freude gelesen.
Die Analogie scheint passend zu sein. Mein Projekt besteht de facto ebenfalls nur aus zwei Dingen: der menschlichen Intent und einem Snapshot.
Letztlich dachte ich, dass die Richtung, in die sich mein Projekt entwickeln sollte, darin besteht, zu berechnen, wie die menschliche Absicht (z. B. Tastatureingaben, Mausklicks) zu verstehen ist und welche Bedeutung sie erhalten soll.
Ich wollte gerade einen Beitrag dazu schreiben, nachdem ich die Veröffentlichung gesehen hatte, aber Sie haben ihn schon verfasst.
Ich bin gespannt, wie leistungsfähig es sein wird.
Da der bestehende Code noch vorhanden ist, kann man selbst prüfen, um welche Implementierung es sich handelt.
https://gitlab.com/sebuls/libhwp
Das Konzept ist attraktiv, aber meiner Erfahrung nach waren solche idealistischen Versuche nur selten erfolgreich..
Bis jetzt scheint Feedly mit seinen AI-Funktionen immer noch am besten und insgesamt am unkompliziertesten zu sein.
rip
Das ist der grundlegende Inhalt, der in den meisten Büchern über agile Methoden vorkommt, etwa Kent Becks Extreme Programming oder Jeff Sutherlands Scrum. Man kann sich auch User Stories ansehen. Die meisten Menschen wissen offenbar nicht genau, dass die Grundlage von Agile kurze Sprints und Demos sind, um sich schnell an Kundenanforderungen anzupassen.
Ich kann Ihrer Meinung gut nachvollziehen.
Es gibt eindeutig Bereiche, die sich nicht durch Code ersetzen lassen.
In diesem Sinne wollte ich es etwas anders ausdrücken: Gut lesbarer Code macht es möglich, dass man keine Dokumentation mehr erstellen muss.
Auch die Dokumentation, die sich im Lauf eines langlebigen Softwareprojekts ansammelt, erzeugt bei Entwicklerinnen und Entwicklern kognitive Belastung. Im Kern geht es darum, die Arbeit zu verringern, ständig zwischen Code und Dokumentation hin- und herzuschalten.
Ich denke nicht, dass am Ende ausschließlich Code übrig bleiben kann.
Ich denke, das kann je nach Kontext und Situation unterschiedlich sein.
Vielen Dank für Ihren Kommentar.
Das wirkt doch einfach nur wie ein Denkanstoß, aber ihr reagiert ja alle ziemlich empfindlich.
Das muss ich auch mal ausprobieren.
Danke für die hilfreichen Informationen.
Um den Einwand vorsichtig zu formulieren: Ich denke nicht, dass Code Dokumentation ersetzen kann. Programmiersprachen verfügen noch nicht über die Ausdrucksstärke und Vermittlungskraft natürlicher Sprache, und ganz praktisch: Wer soll all diesen Code überhaupt komplett lesen?
Zu hoffen und sich zu wünschen, einmal Code zu haben, der Dokumentation ersetzen kann, ist wie der Turmbau zu Babel, den man nie vollenden wird.
Da erscheint es mir sinnvoller, sich lieber gründlich mit OOAD zu beschäftigen.
Was genau bedeutet es, die Spezifikation selbst agil zu schreiben?
Der Kern des Artikels ist doch von vornherein, dass man gar nicht weiß, was Agilität überhaupt ist. Es wurde immer nur darüber geredet, dass Agile diese und jene Eigenschaften habe und man dies und das tun müsse, aber einen Artikel, der tatsächlich zeigt: Das ist ein Produkt, das mit einer agilen Methodik entstanden ist, habe ich bis heute nicht gesehen. Selbst wenn man sich das Manifest ansieht, bleibt es irgendwie vage. Vielleicht könnten Sie einmal ein konkretes Beispiel zeigen.
BckHWP. Excel-VBA-Automatisierung
https://m.blog.naver.com/husky81/222045248589
Bei Gemini CLI wäre es schon schön, wenn es einfach mal richtig funktionieren würde, aber es stürzt ständig ab.
In letzter Zeit sehe ich solche Fälle häufiger.
Ich verstehe es zwar nicht genau, aber ich glaube, ich weiß ungefähr, wie es sich anfühlt.
Vielen Dank.
Ich verstehe nicht, warum man Methodologien so sehr wie heilige Schriften behandelt. Ich finde, dass auch der ursprüngliche Autor zwar nur eine andere Ausrichtung hatte, aber letztlich genauso dogmatisch war.
Ab dem Moment, in dem man sich für SQLite auf einem Produktionsserver entscheidet, muss man sich ständig Gedanken darüber machen, wann man davon wegmigriert.
Früher lohnte sich diese Überlegung, weil die Kosten der DB selbst (Serveranschaffung, IDC, Lizenzkosten usw.) hoch waren,
aber heute lässt sich das Ganze sprichwörtlich per Klick aufsetzen – muss man dann wirklich noch darüber nachdenken?
Schon dieser Text selbst ist nicht agil!
Dem stimme ich zu
Schon allein die Botschaften, die uns der Abbau vertikaler Entscheidungsstrukturen und die iterative Verbesserung in kurzen Zyklen hinterlassen, sind groß (natürlich gilt das ebenso für Projektmanagement-Methoden und -Tools).
Die Schlussfolgerung, dass „Agile selbst keine neuen Einsichten geliefert habe und die Gesamtheit der Menschen, die Agile befürworten, als blinde Agile-Fanatiker diffamiert“ werde, scheint mir etwas überzogen.