1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Software: 20 Dinge…

Weniger ist mehr

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema


  1. Weniger ist mehr

    Autor: mnementh 18.11.21 - 14:09

    Punkt 20 finde ich am Besten:

    > Während Sie ein System von klein auf aufbauen, lernen Sie so viel, dass Sie durch Iterationen am Ende ein viel besseres System bekommen, als Sie jemals von Beginn an hätten entwerfen können. Überraschenderweise ist das vielen Menschen aber schwer zu vermitteln.

    Das entspricht meinen Erfahrungen. Gleich auf ein Problem mit 20 Frameworks draufzuhauen fürht zu Software die schwer zu verstehen ist. Sich die Software von einem kleinen Kern auf aufzubauen funktioniert oft viel besser.

  2. Re: Weniger ist mehr

    Autor: ubuntu_user 18.11.21 - 15:09

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Punkt 20 finde ich am Besten:
    >
    > > Während Sie ein System von klein auf aufbauen, lernen Sie so viel, dass
    > Sie durch Iterationen am Ende ein viel besseres System bekommen, als Sie
    > jemals von Beginn an hätten entwerfen können. Überraschenderweise ist das
    > vielen Menschen aber schwer zu vermitteln.
    >
    > Das entspricht meinen Erfahrungen. Gleich auf ein Problem mit 20 Frameworks
    > draufzuhauen fürht zu Software die schwer zu verstehen ist. Sich die
    > Software von einem kleinen Kern auf aufzubauen funktioniert oft viel
    > besser.


    Das eine hat doch mit dem Anderen nichts zu tun. ich kann auch mit jedem feature ein neues Framework draufklatschen

  3. Re: Weniger ist mehr

    Autor: Allandor 18.11.21 - 15:30

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    >
    > Das eine hat doch mit dem Anderen nichts zu tun. ich kann auch mit jedem
    > feature ein neues Framework draufklatschen

    Jep, kann man machen und 1-2 Jahre später ist man in der neuen DLL-Hölle, weil Beispielsweise ein NPM-Paket nach dem anderen nicht mehr gepflegt oder ersetzt wurde und nun dicke Sicherheitslücken aufweist.
    Also da gilt bei mir der Leitsatz "so wenig wie möglich", das gilt besonders für Abhängigkeiten, die nehmen sonst schnell überhand.

  4. Re: Weniger ist mehr

    Autor: NaruHina 18.11.21 - 17:09

    Wer ist länger als 2 jahre in der it im selben Betrieb...
    Zumindest nach dem was man manchmal hier liest wechselt man doch ständig.

  5. Re: Weniger ist mehr

    Autor: mnementh 18.11.21 - 17:25

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Punkt 20 finde ich am Besten:
    > >
    > > > Während Sie ein System von klein auf aufbauen, lernen Sie so viel,
    > dass
    > > Sie durch Iterationen am Ende ein viel besseres System bekommen, als Sie
    > > jemals von Beginn an hätten entwerfen können. Überraschenderweise ist
    > das
    > > vielen Menschen aber schwer zu vermitteln.
    > >
    > > Das entspricht meinen Erfahrungen. Gleich auf ein Problem mit 20
    > Frameworks
    > > draufzuhauen fürht zu Software die schwer zu verstehen ist. Sich die
    > > Software von einem kleinen Kern auf aufzubauen funktioniert oft viel
    > > besser.
    >
    > Das eine hat doch mit dem Anderen nichts zu tun. ich kann auch mit jedem
    > feature ein neues Framework draufklatschen
    Das meine ich nicht, natürlich sollte man auch beim Wachsen nicht wahllos dranklatschen. Ich meine nur in manchen Projekten hat man von Tag 1 die Abhängigkeitshölle. Ist halt leicht mit lauter Frameworks was zusammenzuklicken und der Chef freut sich auch, ist ja schon fast fertig.

  6. Re: Weniger ist mehr

    Autor: blubberer 18.11.21 - 18:22

    Von wegen Chef freut sich weil schon fast fertig. Wenn ich eines in über 20 Jahren IT gelernt habe, dann das 90% der Arbeit in 10% des Zeitbudget erledigt sind und die restlichen 10% Arbeit/Aufgabe dann (mind.) 90% der Zeit einnehmen. Ist natürlich nicht immer so, aber verdammt oft. Und oft reichen die letzten 90% Zeit nicht aus, sondern man überzieht.

  7. Re: Weniger ist mehr

    Autor: Allandor 18.11.21 - 18:40

    blubberer schrieb:
    --------------------------------------------------------------------------------
    > Von wegen Chef freut sich weil schon fast fertig. Wenn ich eines in über 20
    > Jahren IT gelernt habe, dann das 90% der Arbeit in 10% des Zeitbudget
    > erledigt sind und die restlichen 10% Arbeit/Aufgabe dann (mind.) 90% der
    > Zeit einnehmen. Ist natürlich nicht immer so, aber verdammt oft. Und oft
    > reichen die letzten 90% Zeit nicht aus, sondern man überzieht.
    Naja, seitdem noch der Betrieb der Software dazu gekommen ist, musst du eher 200% Arbeit in 90% der Zeit schaffen ;)

  8. Re: Weniger ist mehr

    Autor: mnementh 18.11.21 - 19:11

    blubberer schrieb:
    --------------------------------------------------------------------------------
    > Von wegen Chef freut sich weil schon fast fertig. Wenn ich eines in über 20
    > Jahren IT gelernt habe, dann das 90% der Arbeit in 10% des Zeitbudget
    > erledigt sind und die restlichen 10% Arbeit/Aufgabe dann (mind.) 90% der
    > Zeit einnehmen. Ist natürlich nicht immer so, aber verdammt oft. Und oft
    > reichen die letzten 90% Zeit nicht aus, sondern man überzieht.

    Ja, mir ist das klar. Den Chefs aber nicht immer.

  9. Re: Weniger ist mehr

    Autor: ubuntu_user 18.11.21 - 19:38

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Das meine ich nicht, natürlich sollte man auch beim Wachsen nicht wahllos
    > dranklatschen. Ich meine nur in manchen Projekten hat man von Tag 1 die
    > Abhängigkeitshölle.

    du dann hat derjenige aber keine Ahnung wie man Software entwickelt und das hat mit agil auch nichts zu tun

  10. Re: Weniger ist mehr

    Autor: captain_spaulding 18.11.21 - 19:59

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Punkt 20 finde ich am Besten:
    >
    > > Während Sie ein System von klein auf aufbauen, lernen Sie so viel, dass
    > Sie durch Iterationen am Ende ein viel besseres System bekommen, als Sie
    > jemals von Beginn an hätten entwerfen können. Überraschenderweise ist das
    > vielen Menschen aber schwer zu vermitteln.
    >
    > Das entspricht meinen Erfahrungen. Gleich auf ein Problem mit 20 Frameworks
    > draufzuhauen fürht zu Software die schwer zu verstehen ist. Sich die
    > Software von einem kleinen Kern auf aufzubauen funktioniert oft viel
    > besser.

    Ich sehe da keinen Bezug zu Frameworks sondern eher altmodischen Entwicklungsprozess vs. agilen Prozess. Ich habe bei mehreren Projekten dieses Muster erkannt:

    In der Industrie hält man es oft für professionell, nicht gleich drauflos zu programmieren. Daher werden erstmal Konzepte und Spezifikationen produziert. Da diese Dokumente in keiner formaler Sprache verfasst werden und es keine Möglichkeit gibt sie automatisiert zu prüfen, strotzen diese hunderte Seiten umfassenden Wälzer nur so vor Widersprüchen und Mehrdeutigkeiten. Manchmal findet ein Mensch einen Fehler, der dann korrigiert wird, aber nur so dass es möglichst wenige Änderungen gibt, weil sonst wäre das ja viel Aufwand. So ist also schon die Grundlage für eine Implementierung historisch gewachsen. Da schon 1 Jahr an der ganzen Dokumentation gearbeitet wurde, ist es an der Zeit es doch mal auszuprobieren, das Management wird nämlich schon unruhig.

    Bei der Implementierung treten dann haufenweise weitere Probleme zu Tage. Im besten Fall sind es nur umzureichende Beschreibungen, im schlechtesten Fall prinzipielle Probleme. Bei Tests fallen Fehler auf an die niemand gedacht hatte.

    Da man nicht wirklich Zeit hat den ganzen Papierkram an die erforderlichen Änderungen anzupassen, archiviert man das ganze zur Prozessbefriedigung statt es wegzuwerfen. Die Software die letztendlich in der Praxis verwendet wird hat damit aber wenig zu tun.

    Mein Fazit:
    Es ist ok ein grobes Konzept aufzuschreiben bevor man in die Implementierung geht. Aber mehr ist völlig unnütz. Ich habe kein nicht-triviales Projekt erlebt, bei dem haufenweise auf theoretischen Überlegungen basierende Spezifikationen in guter Software resultiert hätten.
    Das Verständnis der Systeme ist eben viel größer wenn man etwas ausprobiert und so das Verhalten live sehen kann.
    Klar, es gibt Projekte die einfach drauf los gebastelt wurden und schlecht sind. Aber da wurde dann auch nur so wenig Zeit investiert, dass mit der professionellen Herangehensweise nicht mal die Spezifikation fertig geworden wäre.
    Ich bin daher eher der Ansicht, dass die Software selbst das wichtige ist, nicht die Spezifikation. Code-Driven Development sollte man das nennen.

  11. Re: Weniger ist mehr

    Autor: jkow 18.11.21 - 20:09

    NaruHina schrieb:
    --------------------------------------------------------------------------------
    > Wer ist länger als 2 jahre in der it im selben Betrieb...
    > Zumindest nach dem was man manchmal hier liest wechselt man doch ständig.

    Super Einstellung. Sollen doch die Anderen mit meinem Müll fertig werden.

  12. Re: Weniger ist mehr

    Autor: jkow 18.11.21 - 20:16

    blubberer schrieb:
    --------------------------------------------------------------------------------
    > Von wegen Chef freut sich weil schon fast fertig. Wenn ich eines in über 20
    > Jahren IT gelernt habe, dann das 90% der Arbeit in 10% des Zeitbudget
    > erledigt sind und die restlichen 10% Arbeit/Aufgabe dann (mind.) 90% der
    > Zeit einnehmen. Ist natürlich nicht immer so, aber verdammt oft. Und oft
    > reichen die letzten 90% Zeit nicht aus, sondern man überzieht.

    Das Problem ist hier nicht der Chef sondern die Entwickler, die die Illusion von "fast fertig" kommunizieren und sich wundern, dass der Chef nicht versteht, wenn's dann noch 9x so lange dauert.

    Deshalb: agile Methoden verwenden!

    Früh vertikal integrieren und dann iterativ die Funktionalität vervollständigen. So kann der Chef nachvollziehen, wie der wirkliche Fortschritt ist und wird nicht von der vermeintlichen 90% Funktionalität eines Prototypen geblendet.

  13. Re: Weniger ist mehr

    Autor: ubuntu_user 18.11.21 - 20:21

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------
    > Mein Fazit:
    > Es ist ok ein grobes Konzept aufzuschreiben bevor man in die
    > Implementierung geht. Aber mehr ist völlig unnütz. Ich habe kein
    > nicht-triviales Projekt erlebt, bei dem haufenweise auf theoretischen
    > Überlegungen basierende Spezifikationen in guter Software resultiert
    > hätten.
    > Ich bin daher eher der Ansicht, dass die Software selbst das wichtige ist,
    > nicht die Spezifikation. Code-Driven Development sollte man das nennen.

    naja viel wichtiger als Spezifikation vor der entwicklung ist eigentlich die dokumentation der aktuellen software. Und damit meine ich auch Unittests, Tutorials für neue Mitarbeiter oder eben wie die Konzepte gedacht sind.
    Dazu kommt eben auch dass man weiß wie gewisse Sachen gedacht sind:
    - git/branches
    - npm nicht selbst entwickeln
    - vielleicht auch neue Compiler
    - kein einziges riesiges repository wo zur Einfachheit der ganze Code drin ist
    - wie schreibt man Linux-Treiber
    - UI kenn ich mich nicht so mit aus, da gibts aber ja auch gewisse Konzepte was man macht.

  14. Re: Weniger ist mehr

    Autor: ubuntu_user 18.11.21 - 20:30

    jkow schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ist hier nicht der Chef sondern die Entwickler, die die
    > Illusion von "fast fertig" kommunizieren und sich wundern, dass der Chef
    > nicht versteht, wenn's dann noch 9x so lange dauert.

    aber das ist dann ja auch doof von den Entwicklern ;-)
    manchmal auch lustig. Enwickler jammert, dass schon alles fertig ist und er die nächsten 2-3 Tage nichts zu tun hat.
    "mach doch mal Tests oder fix das was worüber du immer schimpfst"
    ...
    "ich guck mal ob ich noch nen feature im backlog finde"

  15. Re: Weniger ist mehr

    Autor: mnementh 18.11.21 - 21:20

    captain_spaulding schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Punkt 20 finde ich am Besten:
    > >
    > > > Während Sie ein System von klein auf aufbauen, lernen Sie so viel,
    > dass
    > > Sie durch Iterationen am Ende ein viel besseres System bekommen, als Sie
    > > jemals von Beginn an hätten entwerfen können. Überraschenderweise ist
    > das
    > > vielen Menschen aber schwer zu vermitteln.
    > >
    > > Das entspricht meinen Erfahrungen. Gleich auf ein Problem mit 20
    > Frameworks
    > > draufzuhauen fürht zu Software die schwer zu verstehen ist. Sich die
    > > Software von einem kleinen Kern auf aufzubauen funktioniert oft viel
    > > besser.
    >
    > Ich sehe da keinen Bezug zu Frameworks sondern eher altmodischen
    > Entwicklungsprozess vs. agilen Prozess. Ich habe bei mehreren Projekten
    > dieses Muster erkannt:
    >
    > In der Industrie hält man es oft für professionell, nicht gleich drauflos
    > zu programmieren. Daher werden erstmal Konzepte und Spezifikationen
    > produziert. Da diese Dokumente in keiner formaler Sprache verfasst werden
    > und es keine Möglichkeit gibt sie automatisiert zu prüfen, strotzen diese
    > hunderte Seiten umfassenden Wälzer nur so vor Widersprüchen und
    > Mehrdeutigkeiten. Manchmal findet ein Mensch einen Fehler, der dann
    > korrigiert wird, aber nur so dass es möglichst wenige Änderungen gibt, weil
    > sonst wäre das ja viel Aufwand. So ist also schon die Grundlage für eine
    > Implementierung historisch gewachsen. Da schon 1 Jahr an der ganzen
    > Dokumentation gearbeitet wurde, ist es an der Zeit es doch mal
    > auszuprobieren, das Management wird nämlich schon unruhig.
    >
    > Bei der Implementierung treten dann haufenweise weitere Probleme zu Tage.
    > Im besten Fall sind es nur umzureichende Beschreibungen, im schlechtesten
    > Fall prinzipielle Probleme. Bei Tests fallen Fehler auf an die niemand
    > gedacht hatte.
    >
    > Da man nicht wirklich Zeit hat den ganzen Papierkram an die erforderlichen
    > Änderungen anzupassen, archiviert man das ganze zur Prozessbefriedigung
    > statt es wegzuwerfen. Die Software die letztendlich in der Praxis verwendet
    > wird hat damit aber wenig zu tun.
    >
    Du beschreibst ein Projekt das ich kenne. Das wurde von Kundenseite (Uni) vorspezifiziert über großen Zeitraum mit viel Aufwand und vielen Beteiligten, dann suchte man am Ende eine Firma, die es "nur noch implementiert". War ja praktisch schon fertig. Auf dem Papier.

    Alle Entwickler hatten übrigens davon abgeraten sich auf das Projekt zu bewerben.

    > Mein Fazit:
    > Es ist ok ein grobes Konzept aufzuschreiben bevor man in die
    > Implementierung geht. Aber mehr ist völlig unnütz. Ich habe kein
    > nicht-triviales Projekt erlebt, bei dem haufenweise auf theoretischen
    > Überlegungen basierende Spezifikationen in guter Software resultiert
    > hätten.
    Jupp.

    > Das Verständnis der Systeme ist eben viel größer wenn man etwas ausprobiert
    > und so das Verhalten live sehen kann.
    > Klar, es gibt Projekte die einfach drauf los gebastelt wurden und schlecht
    > sind. Aber da wurde dann auch nur so wenig Zeit investiert, dass mit der
    > professionellen Herangehensweise nicht mal die Spezifikation fertig
    > geworden wäre.
    > Ich bin daher eher der Ansicht, dass die Software selbst das wichtige ist,
    > nicht die Spezifikation. Code-Driven Development sollte man das nennen.
    Ja, sehe ich ähnlich.

  16. Re: Weniger ist mehr

    Autor: mnementh 18.11.21 - 21:23

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > captain_spaulding schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Mein Fazit:
    > > Es ist ok ein grobes Konzept aufzuschreiben bevor man in die
    > > Implementierung geht. Aber mehr ist völlig unnütz. Ich habe kein
    > > nicht-triviales Projekt erlebt, bei dem haufenweise auf theoretischen
    > > Überlegungen basierende Spezifikationen in guter Software resultiert
    > > hätten.
    > > Ich bin daher eher der Ansicht, dass die Software selbst das wichtige
    > ist,
    > > nicht die Spezifikation. Code-Driven Development sollte man das nennen.
    >
    > naja viel wichtiger als Spezifikation vor der entwicklung ist eigentlich
    > die dokumentation der aktuellen software. Und damit meine ich auch
    > Unittests, Tutorials für neue Mitarbeiter oder eben wie die Konzepte
    > gedacht sind.
    > Dazu kommt eben auch dass man weiß wie gewisse Sachen gedacht sind:
    > - git/branches
    > - npm nicht selbst entwickeln
    npm ist genauso ein Ding, mit dem ich nur schlecht gemachte Software sehe. Es ist so leicht eine neue Bibliothek ranzuwerfen. Zieht ja alles magisch aus dem Internet, das brauchen wir nicht zu hinterfragen. Bis es halt nicht mehr magisch funktioniert. Dann versteht aber niemand mehr was eigentlich passiert. Um npm-Projekte mache ich lieber einen Bogen.

  17. Re: Weniger ist mehr

    Autor: ubuntu_user 18.11.21 - 22:28

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > npm ist genauso ein Ding, mit dem ich nur schlecht gemachte Software sehe.
    > Es ist so leicht eine neue Bibliothek ranzuwerfen. Zieht ja alles magisch
    > aus dem Internet, das brauchen wir nicht zu hinterfragen. Bis es halt nicht
    > mehr magisch funktioniert. Dann versteht aber niemand mehr was eigentlich
    > passiert. Um npm-Projekte mache ich lieber einen Bogen.

    ich weiß. aber jetzt stell dir vor jemand macht npm nochmal selbst nach

  18. Re: Weniger ist mehr

    Autor: captain_spaulding 18.11.21 - 23:48

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > Du beschreibst ein Projekt das ich kenne. Das wurde von Kundenseite (Uni)
    > vorspezifiziert über großen Zeitraum mit viel Aufwand und vielen
    > Beteiligten, dann suchte man am Ende eine Firma, die es "nur noch
    > implementiert". War ja praktisch schon fertig. Auf dem Papier.
    Kenne ich auch. Vor einigen Jahren hielt man es für eine gute Idee die Spezifikationen einfach nach Indien zu schicken und da implementieren zu lassen. Da sind die Programmierer nämlich viel billiger.
    War aber ein totaler Reinfall, da ist nichts verwendbares raus gekommen. Wurde dann auf die Inder geschoben, aber natürlich lag das auch an miesen Spezifikationen. Ich würde sagen 90% der Spezifikationen sind mies und man kann darauf basierend nichts passendes programmieren.

  19. Re: Weniger ist mehr

    Autor: minnime 19.11.21 - 09:55

    Eine Uni schreibt eine große Spezifikation? Da weiß man ja schon wie das abgelaufen ist. Die Professoren beten ihren Studenten den ganzen Tag vor wie wichtig Planung und Spezifikation ist, haben aber selbst seit Jahren nicht mehr wirklich entwickelt. Am besten lässt man an dieses Projekt dann auch noch Studenten ran, am besten im Rahmen einer Projektgruppe mit mehr als 5 Mann, weil die müssen ja auch mal etwas Erfahrung sammeln und machen dementsprechend was sie gelernt haben. Womöglich wird eine studentische Projektgruppe nicht fertig und man teilt es so auf, dass die einen die Anforderungen erfassen und die Gruppe im nächsten Jahr baut darauf auf und erstellt die Spezifikation.

  20. Re: Weniger ist mehr

    Autor: fabiwanne 19.11.21 - 12:44

    Es gibt npm in Gut: Nennt sich apt/dpkg/deb/reop.
    * Nur gewartete Pakete.
    * Vernünftiges Sicherheitstracking.
    * Abhängigkeiten über die Grenzen einer Programmiersprache hinaus.
    * Multi-Plattform Fähig. (Also verschiedene mit oder verknüpfte Abhängigkeiten)
    * Optionale Abhängigkeiten für Zusatzfunktionalität.

  1. Thema
  1. 1
  2. 2

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Support Engineer für kommunale Software-Anwendungen (m/w/d)
    Anstalt für Kommunale Datenverarbeitung in Bayern (AKDB), verschiedene Standorte
  2. Systemberater (w/m/d) ECM
    VRG MICOS GmbH, Oldenburg, deutschlandweit
  3. CRM Project Manager (m/w/d) Schwerpunkt Salesforce
    LAMILUX Heinrich Strunz GmbH, Rehau (Raum Hof)
  4. Lead Developer (Java) / Solution Architect (m/w/d)
    MLP Finanzberatung SE, Wiesloch

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€
  2. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de