Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Meinung-Softwareentwicklung-ist-keine-Kunst-9755000.html
Softwareentwicklung IST eine Kunst. Man muss kreativ denken können. Und alleine das Wort Effizienz muss hier in vielerlei Richtungen gesehen werden. Codingstyle, Konsistenz, Lesbarkeit, Testbarkeit, zur Verfügung gestellte Schnittstellen, Wiederverwendbarkeit, Performance und aussagekräftige Benamung nur um einiges zu nennen, was ineinandergreifend betrachtet muss. Und selbst wenn man alles beachtet, kommt es immernoch auf das Auge des Betrachters an, ob eine Software als schön bezeichnet werden kann.
Volle Zustimmung! Leider gelten diese Credos nicht für die meisten Hobbyprogrammierer, die sehr oft sogar studiert haben und sich Senior nennen und alles konsequent zerstören. Am schlimmsten sind diejenigen, deren Formatierung wie transpilierter Code aussieht und Merge-Commits für etwas Normales halten, geschweige denn Commit-Nachrichten schreiben können.
Kunst in der Software-Entwicklung sind für mich elegante Algorithmen (Informatik/Mathematik), klevere Problemlösungen (Ingeneering) aber auch klar strukturierte und gut nachvollziehbare Umsetzungen von Programmen (Handwerk). Nicht zu Vergessen die Kunst der Architektur von monumentalen Software-Produkten. Der angesprochene Pragmatismus ist meines Erachtens nach vom Kontext bzw. von den gewünschten und kommunizierten Eigenschaften der Software abhängig. Ich liebe es beim Programmieren, wenn Ideen wie Algorithmen, Clean Code, Test Driving Development, Architektur Design etc. wie von Zauberhand zusammenfinden: Für mich sind die Ideen gepaart mit dem richtigen Pragmatismus eine Kunst - ein Handwerk - eine Handwerkskunst, die den Programmierern und dem Kunden dienlich ist.
@@19DonCorleone87 Sauberer Code wäre wunderbar, nur leider ist "Clean Code" oft eher das Gegenteil davon. Viele Dinge lassen sich mit einer einzigen Formel kurz und knapp formulieren. Oder man setzt "Informatik" ein und erstellt effiziente Datenstrukturen auf Bit-Ebene. Aber da könnte ja wieder eine Abhängigkeit entstehen, also müssen riesige Abstraktionslayer her und die Abhängigkeiten in eine zentrale Bad Bank verschoben werden. Alles soll generalisierter und einfacher werden, aber niemand blickt mehr durch. Am Ende wolltest du nur einen langen Schuhlöffel, um dich nicht bücken zu müssen. Gebaut wurde eine Universal-Anziehhilfemaschine, die selbständig erkennt, ob es ein Schuh, ein Hut oder eine Jacke ist.
Wenn es um ein komplexes Problem geht, ist Abstraktion oft gut, um nachträgliche Anpassungen zu ermöglichen, ohnedaß etwas anderes bricht. Es muß aber nicht jeder Furz ins letzte Detail abstrahiert werden. Und Abstraktion beginnt schon bei einfachen Funktionen. Wenn man die klein hält, spielen Abhängigkeiten auch kaum eine Rolle. Dann fügt man einfach eine neue Funktion hinzu und läßt die alte mit sprechendem Namen stehen, wie sie ist. Interfaces helfen auch nur bedingt. Sie können nicht garantieren, daß das Verhalten auch so implementiert wird wie erwartet. Meines Erachtens machen sie bei Skriptsprachen mit loser Typisierung relativ wenig Sinn. Sie sind ein Werkzeug für Sprachen, wo strenge Typisierung erforderlich ist für späte Bindung. Der Compiler muß die Schnittstelle zu einer DLL wissen.
Letztendlich muß man wissen, wofür man entwickelt. Bei Agenturcode für shoot and forget Projekte lohnt der ganze Aufwand selten. Und wenn der Kunde sich später entscheidet, mehr Features zu wollen, sagt man halt: Man hat ihn gewarnt, das hätte er früher wissen sollen. Jetzt muß alles noch einmal neu konzeptioniert werden. Dafür war die Produktion zuvor halt auch kostengünstig. Nur weil 5-10% der Projekte vielleicht entgegen den Erwartungen doch mal erweitert werden, müssen nicht unbedingt die restliche 90-95% auf Erweiterbarkeit ausgelegt sein. Bei einem langfristig gepflegten internen Framework sieht die Sache schon wieder anders aus.
Meiner Meinung nach ist Programmieren ein Handwerk. Handwerker sind dazu da ein Problem zu lösen oder etwas neues zu schaffen. Dabei muss es aber auch schön aussehen. Was bringt es mir, wenn der Dachdecker mein Dach repariert hat, das dann aber nachher aussieht wie hingek**** und hingesch*****. Das gleiche gilt für die Haltbarkeit. Wenn das Dach repariert ist, soll das bitte auch möglichst lange so bleiben und nicht durch irgendwelche Patzer nächstes Jahr wieder repariert werden müssen. Und wenn Regen droht, muss das Dach schnell repariert sein, damit kein weiterer Schaden entsteht. Software kann also ruhig eine gewisse Ästhetik mitbringen wobei man da auf die Geschwindigkeit und Stabilität achten sollte, was wieder eine gewisse Struktur voraussetzt. Schnell und Effizient soll es dabei aber trotzdem gehen.
Das finde ich eine gute Sichtweise; denn sie zeigt auch ein wenig den Mehrwert, den die Kunst auch im geschäftlichen Kontext bringt. Denn der Kunde wird nicht jede Anforderung an das Dach vorher spezifiziert haben; Dinge wie "soll regendicht sein" werden impliziert. Und wo das Business nun nur möglichst günstig das spezifizierte Problem lösen möchte, ist dem künstlerisch orientierten Handwerker daran gelegen, ein möglichst gutes Dach zu bauen, das hinterher auch regendicht ist. Er möchte eben ein Werk erschaffen, das auch seine eigene Qualität darstellt und wo man hinterher sagen kann: "Qualität by DachdeckerX".
Bin seit über 35 Jahren Entwickler, den größeren Teil der Zeit im full-stack. War angestellt und selbständig, in einem halben Dutzend Branchen von Finanz- bis Gesundheitswesen - und bin mit dem Satz 'Wenn es fertig ist ist es fertig, und vorher nicht!' in der ganzen Zeit überall gut durch gekommen weil: erstens nie jemand da war der hätte beweisen können (oder sich das auch nur getraut hätte) dass sich diese oder jene Aufgabenstellung auch viel schneller erledigen lässt, und zweitens weil jeder der auch nur ein paar Jahre Erfahrung in dem Bereich hat eh weiß, dass im Zweifelsfall nachher doch alles länger dauert, als die ursprünglichen Schätzungen angenommen haben. Fakt ist: würde der durchschnittliche Entwickler REALISTISCH schätzen, dann würden wahrscheinlich die Hälfte der Projekte erst gar nie angefangen, weil der Auftraggeber gleich abwinken würde. Aber das ist ja in anderen Branchen - vor allem der Baubranche - auch nicht anders 😅
Ich freue mich immer wieder deine Videos zu sehen. Ich würde schon den Code meiner Arbeitskollegen als Kunst bezeichnen. Ich bin immer wieder überrascht und beeindruckt wie stilvoll Code geschrieben werden kann.
Schönheit ist ein Nice To Have auf dem Weg zu einer Software, die dem Kunden hilft. Das ist meine Formel. In jedem Fall eine interessante philosophische Betrachtung. 👍
Für mich bewegt sich Softwareentwicklung nicht auf einer linearen Skala, sondern in einem *Dreieck* von Kunst, Handwerk und Wissenschaft. Der Schwerpunkt kann dabei je nach Projekt unterschiedlich sein.
3:45 und 8:20 Ein typischer "Fehler" beim Wort Kunst/Art ist es, nur an bildende Kunst / schöne Künste / fine arts zu denken. Für die Informatik ist aber die Handwerkskunst/Kunstfertigkeit/Kunsthandwerk besser - analog zur Verwendung in anderen Titeln ala "the art of war" oder "art of loving". So eine Handwerkskunst ist trotzdem ein kreativer Prozess, eine "Fingerfertigkeit" - aber es schwingt sowohl der Erwerb von Wissen als auch die Übung und vielleicht auch etwas Talent mit. Und diese kreativen Dinge oder auch das Talent machen den Unterscheid aus zu vielleicht einem normalem MINT-Beruf - ohne das jetzt abwerten zu wollen. Knuth kann natürlich den Begriff so (eingeschränkt/hindefiniert) verwenden, wie er will... wenn er die Handwerkskunst meint, dann stimme ich zu. Es benötigt schon eine Fingerfertigkeit, schönen Code zu schreiben. Wenn er aber bildende/schöne Kunst meint, dann muss ich das deutlich ablehnen - man will keinen Code lesen müssen, der vielleicht "interessant" aussieht aber man ihn sehr schwer versteht oder erst interpretieren (sic) muss, um ihn zu verstehen. Schlechten Code zu schreiben, ist "keine Kunst" - könnte man sagen - denn genau das Gegenteil ist tatsächlich eine stark kreative Leistung. PS: einfach mal bei Wikipedia unter Kunst --> "Etymologie und Wortgebrauch" schauen - das gibt eine neue Perspektive auf die unterschiedlichen Seiten, die mit "Art of Programming" zu verstehen sind (jenseits möglicher eingeschränkter Sichtweisen von Knuth).
Ich habe tatsächlich in dem Script für Compilerbau aus meinem Informatikstudium - auch wenn ich es damals abgebrochen hatte - später noch gelesen, auf dem Sofa. Ohne Laptop dabei. Das war einfach gut.
Interessantes Video und die Aussage, dass sich Kunst nicht schätzen lässt nehme ich mit zu meinem PO/PM wenn er mich im nächsten Spring Planning nach meiner Zeitschätzung frägt. 🤣 Ich denke ich bin damit nicht alleine, wenn ich sage das mir das mit einer unliebsten Tätigkeiten in meinem Beruf als Software Entwickler sind. Aber sie ist halt nun mal notwendig. 😮💨
Nachtrag: Ich seh mich da auf der Skala irgendwie in der Mitte, ich geh mit bei der Aussage das Software Entwicklung eine Kunst sein kann oder ist, aber find auch das die Schönheit nicht nur mit der Eleganz des entwickelten Algorithmus einhergeht, bspw. wie hoch sich Laufzeit des Algorithmus ist. Sondern auch mit Dingen die jetzt vll. nichts in erster Linie mit der programmatischen Lösung des eig. Problems zu tun haben. Wie bspw. das die Software im Nachhinein, auch wartbar und leicht zu verstehen ist. Das eine schließt das andere hierbei nicht aus, ich finde viel eher das beides zusammen gehört. Wir sollten in der heutigen Software Entwicklungs-Welt einfach einen Mittel weg finden zwischen absoluten Künstlern die, aber aufgrund von Termindruck und Deadlines eher Abstriche bei der Eleganz machen, weil das Projekt halt nun mal einfach fertig werden muss und andererseits diesem wahsinnigen Overload an Projektmanagement und allem was mit einhergeht. Das die Entwicklung eines eig. relativ simplen Problems, alleine deswegen Unmengen an Zeit frisst. Meetings, Prozesse usw.
Zeitschätzung ist nicht notwendig, solange man kontinuierlich einen neuen Stand rausbringt und einem vertraut wird, dass die Software Geld verdient. Einfach vorab für jedes Statusmeeting 1-2 Features einplanen, die man zeigen kann, dass Vertrauen aufgebaut wird. Das ist nicht so schwierig eigentlich.
Schätzen kann man alles... Wenn man Unwissend oder unsicher ist, gehen die SPs oder PTs eben einfach nach oben. Und selbst das sind dann eben nur Schätzung. Irgendwann sollte einem dann klar werden in welche Richtung man eher schätzt :)
Ich habe mich in 40 Jahren vom Hacker zum Programmierer, zum Software-Entwickler, zum CleanCode Developer weiterentwickelt. Jetzt achte ich auch auf die Symmetrien im Code, das tendiert dann schon Richtung Kunst, die einen praktischen Nutzen hat: Bessere Lesbarkeit beugt Fehlern vor.
Zu dem PHP-Beispiel: ... is' halt'n Unterschied ob ich 'nen Vorstand glücklich mache oder ob ich Code für 'ne Industrierobotersteuerung oder 'nen Airbus schreibe. Es gibt eben Bereiche, in denen man mit egal welchen Allüren nicht weit kommt.
Ich werde dieses Video jetzt mal einer Hand voll Entwicklern verlinken, die sich selbst als reine Künstler identifizieren... Kein Bock diese Argumentation immer selbst runter zu erzählen, dieses Video fasst es super zusammen.
Um Managern begreiflich zu machen, warum Code-Aufräumen wichtig ist, wurde ja das Konzept der technischen Schulden entwickelt. Mit jedem Feature, das man schnell einbaut, ohne das Drumherum zu beachten, wachsen die technischen Schulden. Auf nicht getilgte Schulden zahlt man Zinsen in Form von Mehraufwand, der nötig ist, um unwartbaren Code zu warten.
Nach über 25 Jahren in dem Job, ist Softwareentwicklung für mich ein Mittel dazu, die Probleme der Anwender zu lösen und zwar so, dass die zufrieden sind, aber auch so, dass der Betrieb, der dahinter steht, so eine Software über Jahre weiterENTWICKELN kann. D.h. auf der einen Seite hast du Kunst (muss ja schon schön aussehen und benutzbar sein) und auf der anderen Handwerk. Du musst Softwareentwicklung einfach lernen und dann merkst du irgendwann gar nicht mehr, ob du DDD oder Clean Code verwendest oder auch nur einen Unit Test schreibst, du machst es einfach. Das Problem bei letzterem sind aber große Organisationen, die meinen, schnell zu Lösungen kommen zu müssen (das Geld muss reinkommen!!!!111elf) und dann fällt mein schöner Text von davor "wunderbar" in sich zusammen. Unter Zeitdruck kann ich weder schönen Code schreiben noch alles so machen, wie die Kundinnen/Kunden es brauchen.
Die künstlerische Seite wird oft belächelt, aber es bringt ja auch echten Business Value ins Team, wenn der Code so verständlich ausformuliert ist, dass Laien bei PP Sessions effektiv mitwirken können. Die meisten Fragen stellen sich nunmal erst, wenn es konkret wird.
Aber ernsthaft. Ich bin da vom Grundverständnis eher bei Robert Martin, der Programmieren ein Handwerk nennt (Craftsmanship). Zu guter Handarbeit gehört zwar auch etwas künstlerisches Geschick, aber dieses hält sich meist in einem sehr pragmatischen Rahmen. Die "Kunst" ist es, es mit Abstaktionsebenen nicht zu übertreiben und nicht ständig irgendwelche Nerdgasmen anzustreben.
Ich sehe das so, wenn das Business niemals mit wünschen von Features oder Anpassungen daher kommt, dann reicht auch eine Datei auf dem Live zu erstellen/editieren. Alles andere ist Clean ein muss
Schönheit und Kunst im Code ist mir auch immer wichtig gewesen, nur leider wissen das viele Arbeitgeber bzw. Kunden nicht zu schätzen. Nur komme ich ohne kaum klar. Aber ich hatte auch schon einen Kunden, bei dem ich im Produktivsystem entwickeln musste. Zwar konnte ich mir dazu entsprechende Sansbox-Tests basteln, aber von dem System hing sehr viel ab (ein Großteil der IT aller zigtausend Mitarbeiter). Der Kunde wusste meinen Einsatz zu schätzen und Ästhetik im Code war kein Problem.
Das Problem ist dass Manager eine Schätzung haben wollen, damit sie genug Punkte in den Sprint quetschen können. Die erzählen was von "Velocity halten". Witzig is nur: die Geschwindigkeit (also Anzahl Punkte/Sprint) wird festgeelegt. Nicht Aufgaben/Zeit=Gechwindigkeit ermittelt. Weil die Leute sich selbst im Engineering nicht an harte Fakten halten wollen. Sie wollen nicht akzeptieren dass Geschwindigkeit unverhandelbar ist.
„Ingenieurskunst“ bei der Suche nach Lösungen und „Handwerkskunst“ bei deren Umsetzung. Oder anders formuliert, empirisch nach Lösungen suchen und die dann mit Best Practices verfolgen. Lösungen ist in der Mehrzahl, weil es nicht immer die eine gibt, sondern eine gesucht ist, die die Ziele erfüllt und mit angemessenen Aufwand erreichbar ist.
Sehr interessante Betrachtungsweise, danke fürs teilen! ...Die Kunst würde in diesem Graubereich dann wohl, wie beim Haus, in der Architektur liegen :)
Software ist für mich wie die Partitur einer Orchester Sinfonie zu schreiben. Muss man die einzelnen Instrumente(Technologien) und Regeln für das Arrangement kennen(-lernen), um zu sehen ob und wo sie eine Rolle spielen. Man kann Instrumente mit anderen "simulieren", aber das führt eben auch schnell zu Misstönen.
Das Beispiel mit dem Typ und der 70k Datei ist fairerweise eine absolute Ausnahme. Nur weil es hier funktioniert hat, heißt das nicht dass es allgemein gültig eine gute Idee ist. All die ganzen Dinge wie Tests, Modularisierung, Clean Code etc. sind aus einer Notwendigkeit heraus entstanden, weil es in vielen Fällen zu katastrophalen Auswirkungen geführt hat. Ich meine der Typ macht vielleicht den Vorstand glücklich, aber was passiert wenn er mal nicht mehr da ist? Keine Sau wird diese Datei anfassen ohne irgendwas grundlegendes kaputt zu machen. Sprich das Management hat ein Damoklesschwert über sich schweben. Das ist nicht smart sondern verantwortungslos. Und ich frag mich auch wie komplex die Software wirklich ist. Es gibt niemanden, der fehlerfreien Code schreibt. Deshalb ich bezweifle, dass der Typ wirklich den besten Code im ganzen Team schreibt. Kann genauso gut sein, dass der code unnötig aufgebläht ist oder vieles davon durch eine lib gelöst werden hätte können.
In der Softwareentwicklung bin ich zum reinen Pragmatiker geworden. Man kann von mir keine künstlerische Seele in einem Projekt verlangen. Wenn jemand einen bestimmten Coding Style haben will, okay I don't care! Ist ein Job, der gut bezahlt wird. Ich male in meiner Freizeit. Da kann ich mich dann wirklich auf die Kunst fokussieren.
Kunst wird das erst dann, wenn das Produkt als "Kunst" intendiert ist -> ansonsten ist das Kunsthandwerk. Aber wenn.... ...dann kann da große, große Kunst.
Von 100% der Menschheit kennt sich nur 1% mit Computern aus. Von 100% der Programmier können nur 1% programmieren. Wenn der Informatiker nicht programmieren kann liegt es an der Programmiersprache. ... Und erfindet die nächste Programmiersprache, die fehlerfrei ist. Praxisbeispiel: Informatiker stellt sich vor, er benutzt C++ weil das die modernere Sprache ist (statt C), er natürlich nur C++ 2024 verwendet, alles andere ist nicht mehr Stand der Technik. Dann bittet man Ihn, kurz das Konzept von OOP zu erläutern und er kann das nicht beantworten. Leider mehrfach so erlebt. Kunst hängt an der Wand und muss nicht funktionieren. Handwerkskunst ist ästhetisch und hat eine Funktion. Informatik als Handwerk erschafft Funktion, Informatik als akademische Disziplin erschafft Konzepte, die vom Handwerker belebt werden müssen.
Eine 70k Zeilen Datei. Da muss es schon irgendwo ums Prinzip gegangen sein. Die Konsequenz Holzwege zu Ende zu gehen. Um sowas zu machen muss sich eine passende Sitation sicher lange entwickeln. Und da bin ich absichtlich vage, denn ich habe keine Vorstellung was hier pasiert ist.
Ich bin noch am Anfang meiner Karriere und bin der Meinung die Funktionalität ist wichtiger als das Design. Aber das könnte sich vielleicht noch ändern…
Nicht nur Softwareentwicklung ist Kunst, sondern auch Hardwareentwicklung ist nich weniger Kunst. Ja, dort sind viele Sachen aus Wissenschaft, aus dem Ingenieur-Fach, jedoch wie schön das realisiert wird - es kann nur Kunst sein.
Software-Engineering ist in erster Linie ein Industrieprozess. Es hat zwar auch künstlerische Aspekte, aber ein schönes Programm, das nicht funktioniert, ist nutzlos. Wer sich ein klassisches Orchesterkonzert anhört, möchte auch, dass die Musiker richtig spielen. Der kreative Akt, findet vorher statt.
Man darf nicht pauschal alles betrachten. Einige von uns bringen Leidenschaft mit in die Entwicklung, auh Entwicklung besteht auch nicht nur vom reinen Coden. Am Kamin habe ich sehr wohl mir meine Konzepte entworfen, auch code geschrieben. Wer will, der sieht Farbe und Kontraste und was noch wichtiger ist - Emotionen bei der Entwicklung von Software. Und für manche ist es nur Arbeit.
Nun die Künstlersozialkasse hat damit kein Problem! Softwareentwicklung und auch Coding ist Kunst, sonst könnte es ja keinen schlechten Code oder schlechte Software geben. Wie löse ich ein Problem? In der Lösung entsteht manchmal eine neue Art der Darstellung und/oder Bedienung, eine Kombination aus dem alten... Und genau deswegen ist es Kunst!
Lol. Ähnliche Beispiele, wie mit den 70k zeilen, haben wir auch in der company. 😅 Am stabilsten laufen "ohne overhead" Applikationen und Services. 😅 Ich kenne auch viele devs mit Profilneurosen. Ich denke es ist auch vom Menschen abhängig und Situationsbedingt. Ich hab schon micro Teams (2 devs) erlebt, mit hardcore scrum, PM, PO usw. Tja, wer hat der kann wa?! 😅 Oder hol dir consultants ins haus. Lol. Zu dritt pair programming und 6 monate Integrationstests schreiben. Nix ist auf prod gelandet nach 2 jahren. Vieles in der it ist hypertrain und wird aufgebauscht. Wenn sie anfangen zu 10t aus Spaghetti türme zu bauen oder lego Enten, bin ich gaaaanz schnell weg.
Also gutes Video!! Knuth ❤ Aber: Die Grundprämisse des Videos ist falsch: Ingenieurswissenschaft sei keine Kunst. Man sagt auch oft "Ingenieurskunst". Das ist irgendwie in Vergessenheit geraten. Wer es nicht glaubt: Theo Jansen, Strandbeest!
Gutes Video, nur in einer Sache stimme ich dir nicht zu, man kann alles schätzen. Viele haben nur nicht den Mut bei Unwissenheit oder Unsicherheit einfach hohe Zahlen zu nennen.
Wenn du Unwissenheit schätzen musst, bedeutet dass, das du dir wissen aneignen musst und deine Schätzung für die aktuelle Anforderung auch nicht sehr gut und hoch ist, aber genau dass kann man eben schätzen. WIssen aneignen + Schätzung mit dem aktuellen Wissenstand + ordentlich Puffer. Da kommen dann eben etwas höhere SPs bei raus und meist macht dann eine Analyse viel Sinn, aber schätzen kann man das. Würdest du Raten, würde dir ja jegliche Entwicklungserfahrung fehlen.
Knuth ist voellig overrated. Er hat Ahnung von Mathematik und Programmierung aber leider 0% Erfahrung von Software Entwicklung (in Teams, mit aendernden Anforderungen). Das zeigt schon sein TeX das er nie mehr aendern will daraus aber Schluesse ziehen will fuer Entwicklung. Literature Programming (Weaver) ist richtig schlecht. Ausserdem ist er einer der Amerikaner der glaubt das die Welt 6000 Jahre alt ist und wir mit Dinosauriern zusammengelebt hatten im Garten Eden.
Vor 40 Jahren war es noch mehr Kunst, aber heute? Obwohl…ich muss mich manchmal wunder, welch schönen Code KI generieren kann, wenn man damit umzugehen weiß.
Sehr schöne Sichtweise. Software kann Kunst sein und die Kombination aus beiden Welten macht meiner Meinung nach am ende den Unterscheid und bringt die Vorteile auf lange Sicht.
Das ist Wasser auf die Mühlen! Nur hängt es wohl eher primär von der Rang- oder Hackordnung innerhalb eines Teams oder Unternehmens ab, ob man mit den von dir genannten Ideen (Testen etc.) das Produkt in-time, in-budget und mit quality abliefern kann. Kunst liegt immer im Auge des Betrachters. Oder wie Sgt. Hartmann es gediegen zu sagen pflegte: „Das ist ja so hässlich, das könnte glatt ein modernes Kunstwerk sein!?!“. Wenn das Team und der Kunde mit „Kunst“ des jeweiligen „Kynschtlers“ klar kommt, dann ist das ja OK. Wird der „Kynschtler“ zur Diva und geht jedem damit auf den Cookie, ist auch keinem geholfen. Umgekehrt gilt das auch für das mittlere oder obere Management. Wenn dort wieder Kunst mit Terminen und Features gemacht wird - jeder der lang genug dabei ist, weiß was gemeint ist. Hat man keine Schulterklappen, wird man weder die hohe Kunst, noch sauberen Pragmatismus vernünftig umsetzen können. Da herrscht dann pures EDD - Ego Driven Develoment. Dennoch sollten auch Künstler ihr Handwerk beherrschen. Ob nun mit Pinsel und Farben, Meisel und Stein oder bei uns mit Instructions und Variablen. Ansonsten ist man Dilletant im heutigen Sinne und der Zufall entscheidet über das Ergebnis. Danke für die inspirierenden Worte zum Montag! Die Aussichten sind weiterhin trüb. 😢
Hallo, also ich hab den Eisbär gesehen und an den Namen Knut gedacht, den Eisbären vom Berliner Zoo ;-) - steht der, wegen der Namensgleichheit, deshalb bei dir?
Der typ mit den 70k zeilen code hat bestimmt nur funktioniert, weil er allein an der datei geschrieben hat. Und richtig gesagt, sobald er weg war haben alle gezittert Es gab keine Tests, keine doku, aber sicher den einen oder anderen bug. Und wenn den ein Kollege fixen sollte, dann war der so lange dran, das es die ganze pragmatische und kostenrechnerische leistung wieder kaputt gemacht hat. Es konnte sicherlicih keiner mehr genau sagen, was der Code macht....
Bin schon mehrmals auf solche "Kunstwerke" gestoßen. Da dürfen sich sehr gerne andere damit vergnügen. Nebenbei, es sagt sehr viel über eine Firma aus, wenn sie solchen Code nutzt oder gar erstellt.
Ich finde dass es einen sehr guten sweet spot dazwischen gibt. Tests und Versionsverwaltung können genauso Business relevant sein und ein fachliches Problem zu lösen kann auch kreativ und spaßig sein. Es macht in meinen Augen auch einen Unterschied in welchem Kontext man entwickelt. Für ein Unternehmen, dass in der Lage sein soll, mein Gehalt zu zahlen? Oder für ein privates Projekt auf einer Hackerkonferenz.
Sehr schön erörtert! Wollte Knuth nicht alle 10 Jahre ein weiteres Band der Reihe herausbringen? In diesem Zusammenhang sei auch bemerkt, dass die Disziplin der Computer Science ganz früher im Bereich 'Arts' angesiedelt war. Später ist sie dann in den Bereich Naturwissenschaft diffundiert, um dann heute oft irgendwo als Ingenieur- oder Bindestrichwissenschaft zu versanden
Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Meinung-Softwareentwicklung-ist-keine-Kunst-9755000.html
Softwareentwicklung IST eine Kunst. Man muss kreativ denken können. Und alleine das Wort Effizienz muss hier in vielerlei Richtungen gesehen werden. Codingstyle, Konsistenz, Lesbarkeit, Testbarkeit, zur Verfügung gestellte Schnittstellen, Wiederverwendbarkeit, Performance und aussagekräftige Benamung nur um einiges zu nennen, was ineinandergreifend betrachtet muss. Und selbst wenn man alles beachtet, kommt es immernoch auf das Auge des Betrachters an, ob eine Software als schön bezeichnet werden kann.
Volle Zustimmung! Leider gelten diese Credos nicht für die meisten Hobbyprogrammierer, die sehr oft sogar studiert haben und sich Senior nennen und alles konsequent zerstören.
Am schlimmsten sind diejenigen, deren Formatierung wie transpilierter Code aussieht und Merge-Commits für etwas Normales halten, geschweige denn Commit-Nachrichten schreiben können.
Kunst in der Software-Entwicklung sind für mich elegante Algorithmen (Informatik/Mathematik), klevere Problemlösungen (Ingeneering) aber auch klar strukturierte und gut nachvollziehbare Umsetzungen von Programmen (Handwerk). Nicht zu Vergessen die Kunst der Architektur von monumentalen Software-Produkten. Der angesprochene Pragmatismus ist meines Erachtens nach vom Kontext bzw. von den gewünschten und kommunizierten Eigenschaften der Software abhängig. Ich liebe es beim Programmieren, wenn Ideen wie Algorithmen, Clean Code, Test Driving Development, Architektur Design etc. wie von Zauberhand zusammenfinden: Für mich sind die Ideen gepaart mit dem richtigen Pragmatismus eine Kunst - ein Handwerk - eine Handwerkskunst, die den Programmierern und dem Kunden dienlich ist.
Clean Code ist ein "scam". Ich empfehle dazu das Video von Ginger Bill (Entwickler der Programmiersprache Odin).
@@19DonCorleone87 Sauberer Code wäre wunderbar, nur leider ist "Clean Code" oft eher das Gegenteil davon. Viele Dinge lassen sich mit einer einzigen Formel kurz und knapp formulieren. Oder man setzt "Informatik" ein und erstellt effiziente Datenstrukturen auf Bit-Ebene.
Aber da könnte ja wieder eine Abhängigkeit entstehen, also müssen riesige Abstraktionslayer her und die Abhängigkeiten in eine zentrale Bad Bank verschoben werden. Alles soll generalisierter und einfacher werden, aber niemand blickt mehr durch.
Am Ende wolltest du nur einen langen Schuhlöffel, um dich nicht bücken zu müssen. Gebaut wurde eine Universal-Anziehhilfemaschine, die selbständig erkennt, ob es ein Schuh, ein Hut oder eine Jacke ist.
Wenn es um ein komplexes Problem geht, ist Abstraktion oft gut, um nachträgliche Anpassungen zu ermöglichen, ohnedaß etwas anderes bricht. Es muß aber nicht jeder Furz ins letzte Detail abstrahiert werden.
Und Abstraktion beginnt schon bei einfachen Funktionen. Wenn man die klein hält, spielen Abhängigkeiten auch kaum eine Rolle. Dann fügt man einfach eine neue Funktion hinzu und läßt die alte mit sprechendem Namen stehen, wie sie ist.
Interfaces helfen auch nur bedingt. Sie können nicht garantieren, daß das Verhalten auch so implementiert wird wie erwartet. Meines Erachtens machen sie bei Skriptsprachen mit loser Typisierung relativ wenig Sinn. Sie sind ein Werkzeug für Sprachen, wo strenge Typisierung erforderlich ist für späte Bindung. Der Compiler muß die Schnittstelle zu einer DLL wissen.
Letztendlich muß man wissen, wofür man entwickelt. Bei Agenturcode für shoot and forget Projekte lohnt der ganze Aufwand selten. Und wenn der Kunde sich später entscheidet, mehr Features zu wollen, sagt man halt: Man hat ihn gewarnt, das hätte er früher wissen sollen. Jetzt muß alles noch einmal neu konzeptioniert werden. Dafür war die Produktion zuvor halt auch kostengünstig. Nur weil 5-10% der Projekte vielleicht entgegen den Erwartungen doch mal erweitert werden, müssen nicht unbedingt die restliche 90-95% auf Erweiterbarkeit ausgelegt sein.
Bei einem langfristig gepflegten internen Framework sieht die Sache schon wieder anders aus.
Meiner Meinung nach ist Programmieren ein Handwerk. Handwerker sind dazu da ein Problem zu lösen oder etwas neues zu schaffen. Dabei muss es aber auch schön aussehen. Was bringt es mir, wenn der Dachdecker mein Dach repariert hat, das dann aber nachher aussieht wie hingek**** und hingesch*****. Das gleiche gilt für die Haltbarkeit. Wenn das Dach repariert ist, soll das bitte auch möglichst lange so bleiben und nicht durch irgendwelche Patzer nächstes Jahr wieder repariert werden müssen. Und wenn Regen droht, muss das Dach schnell repariert sein, damit kein weiterer Schaden entsteht. Software kann also ruhig eine gewisse Ästhetik mitbringen wobei man da auf die Geschwindigkeit und Stabilität achten sollte, was wieder eine gewisse Struktur voraussetzt. Schnell und Effizient soll es dabei aber trotzdem gehen.
Das finde ich eine gute Sichtweise; denn sie zeigt auch ein wenig den Mehrwert, den die Kunst auch im geschäftlichen Kontext bringt. Denn der Kunde wird nicht jede Anforderung an das Dach vorher spezifiziert haben; Dinge wie "soll regendicht sein" werden impliziert. Und wo das Business nun nur möglichst günstig das spezifizierte Problem lösen möchte, ist dem künstlerisch orientierten Handwerker daran gelegen, ein möglichst gutes Dach zu bauen, das hinterher auch regendicht ist. Er möchte eben ein Werk erschaffen, das auch seine eigene Qualität darstellt und wo man hinterher sagen kann: "Qualität by DachdeckerX".
Bin seit über 35 Jahren Entwickler, den größeren Teil der Zeit im full-stack. War angestellt und selbständig, in einem halben Dutzend Branchen von Finanz- bis Gesundheitswesen - und bin mit dem Satz 'Wenn es fertig ist ist es fertig, und vorher nicht!' in der ganzen Zeit überall gut durch gekommen weil: erstens nie jemand da war der hätte beweisen können (oder sich das auch nur getraut hätte) dass sich diese oder jene Aufgabenstellung auch viel schneller erledigen lässt, und zweitens weil jeder der auch nur ein paar Jahre Erfahrung in dem Bereich hat eh weiß, dass im Zweifelsfall nachher doch alles länger dauert, als die ursprünglichen Schätzungen angenommen haben. Fakt ist: würde der durchschnittliche Entwickler REALISTISCH schätzen, dann würden wahrscheinlich die Hälfte der Projekte erst gar nie angefangen, weil der Auftraggeber gleich abwinken würde. Aber das ist ja in anderen Branchen - vor allem der Baubranche - auch nicht anders 😅
Ich freue mich immer wieder deine Videos zu sehen. Ich würde schon den Code meiner Arbeitskollegen als Kunst bezeichnen. Ich bin immer wieder überrascht und beeindruckt wie stilvoll Code geschrieben werden kann.
Schönheit ist ein Nice To Have auf dem Weg zu einer Software, die dem Kunden hilft. Das ist meine Formel. In jedem Fall eine interessante philosophische Betrachtung. 👍
Die PHP Skript Story bringt Erinnerungen an meine Ausbildung zurück xD
Für mich bewegt sich Softwareentwicklung nicht auf einer linearen Skala, sondern in einem *Dreieck* von Kunst, Handwerk und Wissenschaft. Der Schwerpunkt kann dabei je nach Projekt unterschiedlich sein.
Sehr schönes Bild, fast schon poetisch! 😉
3:45 und 8:20 Ein typischer "Fehler" beim Wort Kunst/Art ist es, nur an bildende Kunst / schöne Künste / fine arts zu denken. Für die Informatik ist aber die Handwerkskunst/Kunstfertigkeit/Kunsthandwerk besser - analog zur Verwendung in anderen Titeln ala "the art of war" oder "art of loving". So eine Handwerkskunst ist trotzdem ein kreativer Prozess, eine "Fingerfertigkeit" - aber es schwingt sowohl der Erwerb von Wissen als auch die Übung und vielleicht auch etwas Talent mit. Und diese kreativen Dinge oder auch das Talent machen den Unterscheid aus zu vielleicht einem normalem MINT-Beruf - ohne das jetzt abwerten zu wollen.
Knuth kann natürlich den Begriff so (eingeschränkt/hindefiniert) verwenden, wie er will... wenn er die Handwerkskunst meint, dann stimme ich zu. Es benötigt schon eine Fingerfertigkeit, schönen Code zu schreiben. Wenn er aber bildende/schöne Kunst meint, dann muss ich das deutlich ablehnen - man will keinen Code lesen müssen, der vielleicht "interessant" aussieht aber man ihn sehr schwer versteht oder erst interpretieren (sic) muss, um ihn zu verstehen. Schlechten Code zu schreiben, ist "keine Kunst" - könnte man sagen - denn genau das Gegenteil ist tatsächlich eine stark kreative Leistung.
PS: einfach mal bei Wikipedia unter Kunst --> "Etymologie und Wortgebrauch" schauen - das gibt eine neue Perspektive auf die unterschiedlichen Seiten, die mit "Art of Programming" zu verstehen sind (jenseits möglicher eingeschränkter Sichtweisen von Knuth).
Ich habe tatsächlich in dem Script für Compilerbau aus meinem Informatikstudium - auch wenn ich es damals abgebrochen hatte - später noch gelesen, auf dem Sofa. Ohne Laptop dabei. Das war einfach gut.
Interessantes Video und die Aussage, dass sich Kunst nicht schätzen lässt nehme ich mit zu meinem PO/PM wenn er mich im nächsten Spring Planning nach meiner Zeitschätzung frägt. 🤣 Ich denke ich bin damit nicht alleine, wenn ich sage das mir das mit einer unliebsten Tätigkeiten in meinem Beruf als Software Entwickler sind. Aber sie ist halt nun mal notwendig. 😮💨
Nachtrag: Ich seh mich da auf der Skala irgendwie in der Mitte, ich geh mit bei der Aussage das Software Entwicklung eine Kunst sein kann oder ist, aber find auch das die Schönheit nicht nur mit der Eleganz des entwickelten Algorithmus einhergeht, bspw. wie hoch sich Laufzeit des Algorithmus ist. Sondern auch mit Dingen die jetzt vll. nichts in erster Linie mit der programmatischen Lösung des eig. Problems zu tun haben. Wie bspw. das die Software im Nachhinein, auch wartbar und leicht zu verstehen ist. Das eine schließt das andere hierbei nicht aus, ich finde viel eher das beides zusammen gehört. Wir sollten in der heutigen Software Entwicklungs-Welt einfach einen Mittel weg finden zwischen absoluten Künstlern die, aber aufgrund von Termindruck und Deadlines eher Abstriche bei der Eleganz machen, weil das Projekt halt nun mal einfach fertig werden muss und andererseits diesem wahsinnigen Overload an Projektmanagement und allem was mit einhergeht. Das die Entwicklung eines eig. relativ simplen Problems, alleine deswegen Unmengen an Zeit frisst. Meetings, Prozesse usw.
Zeitschätzung ist nicht notwendig, solange man kontinuierlich einen neuen Stand rausbringt und einem vertraut wird, dass die Software Geld verdient.
Einfach vorab für jedes Statusmeeting 1-2 Features einplanen, die man zeigen kann, dass Vertrauen aufgebaut wird. Das ist nicht so schwierig eigentlich.
Schätzen kann man alles... Wenn man Unwissend oder unsicher ist, gehen die SPs oder PTs eben einfach nach oben. Und selbst das sind dann eben nur Schätzung. Irgendwann sollte einem dann klar werden in welche Richtung man eher schätzt :)
Ich habe mich in 40 Jahren vom Hacker zum Programmierer, zum Software-Entwickler, zum CleanCode Developer weiterentwickelt.
Jetzt achte ich auch auf die Symmetrien im Code, das tendiert dann schon Richtung Kunst, die einen praktischen Nutzen hat: Bessere Lesbarkeit beugt Fehlern vor.
Zu dem PHP-Beispiel:
... is' halt'n Unterschied ob ich 'nen Vorstand glücklich mache oder ob ich Code für 'ne Industrierobotersteuerung oder 'nen Airbus schreibe.
Es gibt eben Bereiche, in denen man mit egal welchen Allüren nicht weit kommt.
Ich werde dieses Video jetzt mal einer Hand voll Entwicklern verlinken, die sich selbst als reine Künstler identifizieren... Kein Bock diese Argumentation immer selbst runter zu erzählen, dieses Video fasst es super zusammen.
Um Managern begreiflich zu machen, warum Code-Aufräumen wichtig ist, wurde ja das Konzept der technischen Schulden entwickelt. Mit jedem Feature, das man schnell einbaut, ohne das Drumherum zu beachten, wachsen die technischen Schulden. Auf nicht getilgte Schulden zahlt man Zinsen in Form von Mehraufwand, der nötig ist, um unwartbaren Code zu warten.
".. die Kelle des Maestros nicht den richtigen Schwung findet..." xD
An dieser Stelle habe ich einen gepflegten ROTFL eingelegt! GENIAL! xD
Danke 🤣
Nach über 25 Jahren in dem Job, ist Softwareentwicklung für mich ein Mittel dazu, die Probleme der Anwender zu lösen und zwar so, dass die zufrieden sind, aber auch so, dass der Betrieb, der dahinter steht, so eine Software über Jahre weiterENTWICKELN kann. D.h. auf der einen Seite hast du Kunst (muss ja schon schön aussehen und benutzbar sein) und auf der anderen Handwerk. Du musst Softwareentwicklung einfach lernen und dann merkst du irgendwann gar nicht mehr, ob du DDD oder Clean Code verwendest oder auch nur einen Unit Test schreibst, du machst es einfach.
Das Problem bei letzterem sind aber große Organisationen, die meinen, schnell zu Lösungen kommen zu müssen (das Geld muss reinkommen!!!!111elf) und dann fällt mein schöner Text von davor "wunderbar" in sich zusammen. Unter Zeitdruck kann ich weder schönen Code schreiben noch alles so machen, wie die Kundinnen/Kunden es brauchen.
Die künstlerische Seite wird oft belächelt, aber es bringt ja auch echten Business Value ins Team, wenn der Code so verständlich ausformuliert ist, dass Laien bei PP Sessions effektiv mitwirken können. Die meisten Fragen stellen sich nunmal erst, wenn es konkret wird.
Der Typ mit der 70.000-Zeilen-Datei muss Tom heißen, denn "Tom is a genius".
Aber ernsthaft. Ich bin da vom Grundverständnis eher bei Robert Martin, der Programmieren ein Handwerk nennt (Craftsmanship).
Zu guter Handarbeit gehört zwar auch etwas künstlerisches Geschick, aber dieses hält sich meist in einem sehr pragmatischen Rahmen.
Die "Kunst" ist es, es mit Abstaktionsebenen nicht zu übertreiben und nicht ständig irgendwelche Nerdgasmen anzustreben.
Ich sehe das so, wenn das Business niemals mit wünschen von Features oder Anpassungen daher kommt, dann reicht auch eine Datei auf dem Live zu erstellen/editieren. Alles andere ist Clean ein muss
Schönheit und Kunst im Code ist mir auch immer wichtig gewesen, nur leider wissen das viele Arbeitgeber bzw. Kunden nicht zu schätzen. Nur komme ich ohne kaum klar.
Aber ich hatte auch schon einen Kunden, bei dem ich im Produktivsystem entwickeln musste. Zwar konnte ich mir dazu entsprechende Sansbox-Tests basteln, aber von dem System hing sehr viel ab (ein Großteil der IT aller zigtausend Mitarbeiter). Der Kunde wusste meinen Einsatz zu schätzen und Ästhetik im Code war kein Problem.
Spannendes kleines Buch zum Thema: Hackers and Painters von Paul Graham.
Oh ja, das kann ich auch nur empfehlen 😊
Japp. Und The Pragmatic Programmer hat mich damals auch beeinflusst.
Das Problem ist dass Manager eine Schätzung haben wollen, damit sie genug Punkte in den Sprint quetschen können. Die erzählen was von "Velocity halten". Witzig is nur: die Geschwindigkeit (also Anzahl Punkte/Sprint) wird festgeelegt. Nicht Aufgaben/Zeit=Gechwindigkeit ermittelt. Weil die Leute sich selbst im Engineering nicht an harte Fakten halten wollen. Sie wollen nicht akzeptieren dass Geschwindigkeit unverhandelbar ist.
„Ingenieurskunst“ bei der Suche nach Lösungen und „Handwerkskunst“ bei deren Umsetzung. Oder anders formuliert, empirisch nach Lösungen suchen und die dann mit Best Practices verfolgen. Lösungen ist in der Mehrzahl, weil es nicht immer die eine gibt, sondern eine gesucht ist, die die Ziele erfüllt und mit angemessenen Aufwand erreichbar ist.
Sehr interessante Betrachtungsweise, danke fürs teilen! ...Die Kunst würde in diesem Graubereich dann wohl, wie beim Haus, in der Architektur liegen :)
Software ist für mich wie die Partitur einer Orchester Sinfonie zu schreiben. Muss man die einzelnen Instrumente(Technologien) und Regeln für das Arrangement kennen(-lernen), um zu sehen ob und wo sie eine Rolle spielen. Man kann Instrumente mit anderen "simulieren", aber das führt eben auch schnell zu Misstönen.
Das Beispiel mit dem Typ und der 70k Datei ist fairerweise eine absolute Ausnahme. Nur weil es hier funktioniert hat, heißt das nicht dass es allgemein gültig eine gute Idee ist. All die ganzen Dinge wie Tests, Modularisierung, Clean Code etc. sind aus einer Notwendigkeit heraus entstanden, weil es in vielen Fällen zu katastrophalen Auswirkungen geführt hat.
Ich meine der Typ macht vielleicht den Vorstand glücklich, aber was passiert wenn er mal nicht mehr da ist? Keine Sau wird diese Datei anfassen ohne irgendwas grundlegendes kaputt zu machen. Sprich das Management hat ein Damoklesschwert über sich schweben.
Das ist nicht smart sondern verantwortungslos. Und ich frag mich auch wie komplex die Software wirklich ist. Es gibt niemanden, der fehlerfreien Code schreibt. Deshalb ich bezweifle, dass der Typ wirklich den besten Code im ganzen Team schreibt. Kann genauso gut sein, dass der code unnötig aufgebläht ist oder vieles davon durch eine lib gelöst werden hätte können.
In der Softwareentwicklung bin ich zum reinen Pragmatiker geworden. Man kann von mir keine künstlerische Seele in einem Projekt verlangen. Wenn jemand einen bestimmten Coding Style haben will, okay I don't care! Ist ein Job, der gut bezahlt wird. Ich male in meiner Freizeit. Da kann ich mich dann wirklich auf die Kunst fokussieren.
Kunst wird das erst dann, wenn das Produkt als "Kunst" intendiert ist -> ansonsten ist das Kunsthandwerk.
Aber wenn.... ...dann kann da große, große Kunst.
Hat der liebe Donald nicht auch das das Satzsystem TeX "erfunden". Alleine dafür müsste er schon einen Platz direkt neben dem lieben Gott kriegen.
Von 100% der Menschheit kennt sich nur 1% mit Computern aus. Von 100% der Programmier können nur 1% programmieren.
Wenn der Informatiker nicht programmieren kann liegt es an der Programmiersprache. ... Und erfindet die nächste Programmiersprache, die fehlerfrei ist.
Praxisbeispiel: Informatiker stellt sich vor, er benutzt C++ weil das die modernere Sprache ist (statt C), er natürlich nur C++ 2024 verwendet, alles andere ist nicht mehr Stand der Technik. Dann bittet man Ihn, kurz das Konzept von OOP zu erläutern und er kann das nicht beantworten. Leider mehrfach so erlebt.
Kunst hängt an der Wand und muss nicht funktionieren. Handwerkskunst ist ästhetisch und hat eine Funktion.
Informatik als Handwerk erschafft Funktion, Informatik als akademische Disziplin erschafft Konzepte, die vom Handwerker belebt werden müssen.
Eine 70k Zeilen Datei. Da muss es schon irgendwo ums Prinzip gegangen sein. Die Konsequenz Holzwege zu Ende zu gehen.
Um sowas zu machen muss sich eine passende Sitation sicher lange entwickeln.
Und da bin ich absichtlich vage, denn ich habe keine Vorstellung was hier pasiert ist.
Ich bin noch am Anfang meiner Karriere und bin der Meinung die Funktionalität ist wichtiger als das Design. Aber das könnte sich vielleicht noch ändern…
Nicht nur Softwareentwicklung ist Kunst, sondern auch Hardwareentwicklung ist nich weniger Kunst. Ja, dort sind viele Sachen aus Wissenschaft, aus dem Ingenieur-Fach, jedoch wie schön das realisiert wird - es kann nur Kunst sein.
Ich habe schon öfter Code bewundert 😂
Software-Engineering ist in erster Linie ein Industrieprozess. Es hat zwar auch künstlerische Aspekte, aber ein schönes Programm, das nicht funktioniert, ist nutzlos. Wer sich ein klassisches Orchesterkonzert anhört, möchte auch, dass die Musiker richtig spielen. Der kreative Akt, findet vorher statt.
Vielleicht wäre die Unterscheidung zwischen Kunst und Kunsthandwerk fruchtbar.
Schönes interessantes Video, danke Golo. ❤
Das freut mich, vielen Dank 😊
Man darf nicht pauschal alles betrachten. Einige von uns bringen Leidenschaft mit in die Entwicklung, auh Entwicklung besteht auch nicht nur vom reinen Coden. Am Kamin habe ich sehr wohl mir meine Konzepte entworfen, auch code geschrieben. Wer will, der sieht Farbe und Kontraste und was noch wichtiger ist - Emotionen bei der Entwicklung von Software. Und für manche ist es nur Arbeit.
Nun die Künstlersozialkasse hat damit kein Problem! Softwareentwicklung und auch Coding ist Kunst, sonst könnte es ja keinen schlechten Code oder schlechte Software geben. Wie löse ich ein Problem? In der Lösung entsteht manchmal eine neue Art der Darstellung und/oder Bedienung, eine Kombination aus dem alten... Und genau deswegen ist es Kunst!
Lol. Ähnliche Beispiele, wie mit den 70k zeilen, haben wir auch in der company. 😅 Am stabilsten laufen "ohne overhead" Applikationen und Services. 😅
Ich kenne auch viele devs mit Profilneurosen. Ich denke es ist auch vom Menschen abhängig und Situationsbedingt. Ich hab schon micro Teams (2 devs) erlebt, mit hardcore scrum, PM, PO usw. Tja, wer hat der kann wa?! 😅
Oder hol dir consultants ins haus. Lol. Zu dritt pair programming und 6 monate Integrationstests schreiben. Nix ist auf prod gelandet nach 2 jahren. Vieles in der it ist hypertrain und wird aufgebauscht.
Wenn sie anfangen zu 10t aus Spaghetti türme zu bauen oder lego Enten, bin ich gaaaanz schnell weg.
Also gutes Video!! Knuth ❤ Aber: Die Grundprämisse des Videos ist falsch: Ingenieurswissenschaft sei keine Kunst. Man sagt auch oft "Ingenieurskunst". Das ist irgendwie in Vergessenheit geraten. Wer es nicht glaubt: Theo Jansen, Strandbeest!
Robert C. Martin?
Anwendungen zu erstellen ist Kunst.
Hätte gerne gesehen was passiert wäre, wenn an der 70000 Zeilen PHP Datei mehrere Entwickler gearbeitet hätten ohne Tests, CI/CD, Git usw. 😅
Solange sie nicht exakt die gleichen Zeilen anpassen, ist alles gut 🤣
Elvis ?:
Nicht ganz 😉
(Also ich hab' nix gegen Elvis, aber ich schreie auch nicht "juhuu")
Lisp
Stimmt 😊
Gleich zwei klassische Fehlschlüsse in einem Video: 1. Popularitätsargument 2. Argument to moderation oder argument from middle ground.
Ganz klar: Niemand mag Bus-Factor=1
Uncle bob
Tatsächlich eher weniger 😉
Gutes Video, nur in einer Sache stimme ich dir nicht zu, man kann alles schätzen. Viele haben nur nicht den Mut bei Unwissenheit oder Unsicherheit einfach hohe Zahlen zu nennen.
Wenn ich unwissend bin, *kann* ich es nicht schätzen - ich kann bestenfalls raten.
Wenn du Unwissenheit schätzen musst, bedeutet dass, das du dir wissen aneignen musst und deine Schätzung für die aktuelle Anforderung auch nicht sehr gut und hoch ist, aber genau dass kann man eben schätzen.
WIssen aneignen + Schätzung mit dem aktuellen Wissenstand + ordentlich Puffer. Da kommen dann eben etwas höhere SPs bei raus und meist macht dann eine Analyse viel Sinn, aber schätzen kann man das.
Würdest du Raten, würde dir ja jegliche Entwicklungserfahrung fehlen.
Pragmatismus
Naja - fast :D
Wie Du schon sagst: Fast 😉
Knuth. Sekunden später: verrückter Treffer! Aber mein Prof war ein Knuth Fan - hat sich bei mir definitiv auch verfangen.
Wow 😊
Knuth ist voellig overrated. Er hat Ahnung von Mathematik und Programmierung aber leider 0% Erfahrung von Software Entwicklung (in Teams, mit aendernden Anforderungen). Das zeigt schon sein TeX das er nie mehr aendern will daraus aber Schluesse ziehen will fuer Entwicklung. Literature Programming (Weaver) ist richtig schlecht.
Ausserdem ist er einer der Amerikaner der glaubt das die Welt 6000 Jahre alt ist und wir mit Dinosauriern zusammengelebt hatten im Garten Eden.
Vor 40 Jahren war es noch mehr Kunst, aber heute? Obwohl…ich muss mich manchmal wunder, welch schönen Code KI generieren kann, wenn man damit umzugehen weiß.
Sehr schöne Sichtweise. Software kann Kunst sein und die Kombination aus beiden Welten macht meiner Meinung nach am ende den Unterscheid und bringt die Vorteile auf lange Sicht.
Das ist Wasser auf die Mühlen! Nur hängt es wohl eher primär von der Rang- oder Hackordnung innerhalb eines Teams oder Unternehmens ab, ob man mit den von dir genannten Ideen (Testen etc.) das Produkt in-time, in-budget und mit quality abliefern kann. Kunst liegt immer im Auge des Betrachters. Oder wie Sgt. Hartmann es gediegen zu sagen pflegte: „Das ist ja so hässlich, das könnte glatt ein modernes Kunstwerk sein!?!“. Wenn das Team und der Kunde mit „Kunst“ des jeweiligen „Kynschtlers“ klar kommt, dann ist das ja OK. Wird der „Kynschtler“ zur Diva und geht jedem damit auf den Cookie, ist auch keinem geholfen. Umgekehrt gilt das auch für das mittlere oder obere Management. Wenn dort wieder Kunst mit Terminen und Features gemacht wird - jeder der lang genug dabei ist, weiß was gemeint ist.
Hat man keine Schulterklappen, wird man weder die hohe Kunst, noch sauberen Pragmatismus vernünftig umsetzen können. Da herrscht dann pures EDD - Ego Driven Develoment.
Dennoch sollten auch Künstler ihr Handwerk beherrschen. Ob nun mit Pinsel und Farben, Meisel und Stein oder bei uns mit Instructions und Variablen. Ansonsten ist man Dilletant im heutigen Sinne und der Zufall entscheidet über das Ergebnis.
Danke für die inspirierenden Worte zum Montag! Die Aussichten sind weiterhin trüb. 😢
Im Studium wurde ich öfter gefragt, ob ich mit ihm verwandt sei, da ich den gleichen Nachnamen trage 😁 1:26
Hallo, also ich hab den Eisbär gesehen und an den Namen Knut gedacht, den Eisbären vom Berliner Zoo ;-) - steht der, wegen der Namensgleichheit, deshalb bei dir?
Haha, nein (wobei das eine schöne Anekdote wäre) 😊
Ich mag einfach Eisbären sehr gerne 🐻❄️❤️
Ist das Kunst oder kann das weg?
Robert C. Martin(Uncle Bob) - Knuth geht aber voll klar!
Mit Robert C. Martin liege ich tatsächlich _nicht_ so sehr auf eine Wellenlänge … 😉
Der typ mit den 70k zeilen code hat bestimmt nur funktioniert, weil er allein an der datei geschrieben hat. Und richtig gesagt, sobald er weg war haben alle gezittert
Es gab keine Tests, keine doku, aber sicher den einen oder anderen bug. Und wenn den ein Kollege fixen sollte, dann war der so lange dran, das es die ganze pragmatische und kostenrechnerische leistung wieder kaputt gemacht hat.
Es konnte sicherlicih keiner mehr genau sagen, was der Code macht....
Bin schon mehrmals auf solche "Kunstwerke" gestoßen. Da dürfen sich sehr gerne andere damit vergnügen.
Nebenbei, es sagt sehr viel über eine Firma aus, wenn sie solchen Code nutzt oder gar erstellt.
Das Phänomen nennt sich technische Schulden. Vordergründig funktioniert es zwar, aber der Bus-Faktor ist 1.
Ich finde dass es einen sehr guten sweet spot dazwischen gibt. Tests und Versionsverwaltung können genauso Business relevant sein und ein fachliches Problem zu lösen kann auch kreativ und spaßig sein.
Es macht in meinen Augen auch einen Unterschied in welchem Kontext man entwickelt. Für ein Unternehmen, dass in der Lage sein soll, mein Gehalt zu zahlen? Oder für ein privates Projekt auf einer Hackerkonferenz.
Susanna
Awwww 🥰🥰🥰🥰🥰
Steffi Lemke
TBH - ich musste erst mal googlen, wer das ist 😉
Sehr schön erörtert! Wollte Knuth nicht alle 10 Jahre ein weiteres Band der Reihe herausbringen?
In diesem Zusammenhang sei auch bemerkt, dass die Disziplin der Computer Science ganz früher im Bereich 'Arts' angesiedelt war. Später ist sie dann in den Bereich Naturwissenschaft diffundiert, um dann heute oft irgendwo als Ingenieur- oder Bindestrichwissenschaft zu versanden
Wann war denn das?
An meiner Uni hat Infomatik zunächst zur Mathematik gehört.
@@michaelburggraf2822 Die Diskussionen über die Zuordnung der Informatik hatten in der Mitte bis Ende der 1970er Jahre ihren Höhepunkt