1. Foren
  2. Kommentare
  3. Automobil
  4. Alle Kommentare zum Artikel
  5. › Pannenproduktion: Volkswagen ID.3…

Wie skaliert und beschleunigt man Software-Entwicklung?

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema

Neues Thema Ansicht wechseln


  1. Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: abdul el alamein 25.05.20 - 01:28

    Zitat Musk:
    "... There are very few excellent software engineers & merely increasing team size results in awful bloatware."

    Bei VW hat man wohl (wie so oft in D) einfach Geld und noch mehr Leute auf das Problem geworfen, und dann ist man halt mit Bloatware rausgekommen.

    Leider lässt sich dann bei Software nichts mehr kurzfristig "fixen".

    Ich kann mit einem Team aus 5 guten Leuten deutlich schneller sein als ein "Projekt" mit 20 Entwicklern (das ist nicht "abstrakt" gemeint, sondern real, als Erfahrungswert).

    Es gibt fast keine Devs (geschweige denn Manager), die iterative Entwicklung verstehen und können - iterative Entwicklung mit ständiger Integration ist aber für sowas wie OTA ein Muss. Sonst kriegt man es einfach nicht hin.

    Es ist oft schwer Devs davon zu überzeugen nur ein kleines Bisschen Funktionalität hinzuzucoden, ohne YAGNI-Shit, aber dieses Bisschen richtig gut zu machen. Viele denken "ach das Bisschen, das mach ich Mal schnell hacky-hacky". Und sie hoffen oder glauben irgendwie daran, dass man die Sachen erst groß machen muss um sie "richtig" zu machen.

  2. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: flikens 25.05.20 - 07:48

    Ist das wirklich so? Ich dachte wenn mehr Programmierer zur Verfügung stehen, können die sich auf unterschiedliche Bereich fokussieren und somit parallel entwickeln.

  3. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: burzum 25.05.20 - 08:02

    abdul el alamein schrieb:
    --------------------------------------------------------------------------------

    > Es ist oft schwer Devs davon zu überzeugen nur ein kleines Bisschen
    > Funktionalität hinzuzucoden, ohne YAGNI-Shit, aber dieses Bisschen richtig
    > gut zu machen.

    Ich gehe bei allem anderen vollkommen mit, das hier würde ich aber so nicht stehen lassen. Wenn ich mir ansehe was für eine sinnfreie Grütze teils verlangt wird, wo ich mich frage welchen finanziellen Benefit das abwirft, wir aber nicht einfach sagen können "Nö, machen wir nicht", dann liegt der Ball das zu viel unnützer Müll gemacht wird, selten im Feld der IT. Oft heißt es simpel "Bück dich Fee, Wunsch ist Wunsch."

    Wir hatten z.B. übersetzbare Date Ranges, da sollte dann halt zum Beispiel stehen "Vom 12.12.2019 bis 1.1.2020" wenn es über Jahres Ende ging. Ansonsten halt nur "Vom 01.12. bis 12.12." davon gab es noch einen Sack voller Cases, auch mit Uhrzeiten, so das in einer anderen Sprache zum Beispiel der Monat ausgeschrieben werden sollte. So weit so gut und noch einfach. Jetzt mußte das ganze natürlich in X Sprachen gehen, unter anderem Japanisch, Chinesisch und so weiter. Jetzt waren die Zuständigen der jeweiligen Plattform nicht mit der generischen Formatierung glücklich und es endete damit, das sehr viel Zeit dafür aufgewendet wurde diesen Mist so anpassbar zu machen, das sie dem Gusto des Verantwortlichen entsprochen haben. Im Prinzip beschreibt jetzt ein Objekt pro Sprache die Logik und behandelt jeden Case (glaube es waren knapp 20), so das jeder Furz wenn nötig dem Wunsch des Verantwortlichen nach geändert werden kann. Die Begründung dafür auf Nachfrage war, das unsere Kundschaft ja Wert auf solche Details legen würde. Das Produkt um das es geht ist übrigens eine Website. Auf die Nachfrage wie man zu dem Schluß kommt kam nichts. Und das ist nur EIN Beispiel für Dinge die maximal verkompliziert wurden. Als ob ein ISO 8601 Date nicht auch gereicht hätte fürs Erste MVP bis wirklich mal wer über ein ISO 8601 geheult hätte. Was vermutlich nie passiert wäre.

    flikens schrieb:
    --------------------------------------------------------------------------------
    > Ist das wirklich so? Ich dachte wenn mehr Programmierer zur Verfügung
    > stehen, können die sich auf unterschiedliche Bereich fokussieren und somit
    > parallel entwickeln.

    Wunsch und Realität laufen hier leider oft aneinander vorbei. Das Problem was man aus den Medien so vermuten kann ist, das VM genau das gemacht hat aber "vergessen" hat dafür zu sorgen, das hinterher alles irgendwie auch zusammen läuft. Die Architektur ist ein Technisches Problem, ja, das ganze zu managen aber das eines Projektleiters / Managers.

    Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.



    3 mal bearbeitet, zuletzt am 25.05.20 08:07 durch burzum.

  4. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: flikens 25.05.20 - 08:34

    burzum schrieb:
    --------------------------------------------------------------------------------
    > Wunsch und Realität laufen hier leider oft aneinander vorbei. Das Problem
    > was man aus den Medien so vermuten kann ist, das VM genau das gemacht hat
    > aber "vergessen" hat dafür zu sorgen, das hinterher alles irgendwie auch
    > zusammen läuft. Die Architektur ist ein Technisches Problem, ja, das ganze
    > zu managen aber das eines Projektleiters / Managers.

    Ich dachte immer einer der Vorteile von OOP sei, dass Daten ans Objekt gefüttert werden und dann das Resultat herauskommt - also eben gerade, dass man "nicht" darauf achten muss, dass es zusammen läuft, weil das bei OOP kein Problem sei es zusammen lauffähig zu machen.

  5. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: burzum 25.05.20 - 09:00

    flikens schrieb:
    --------------------------------------------------------------------------------
    > Ich dachte immer einer der Vorteile von OOP sei, dass Daten ans Objekt
    > gefüttert werden und dann das Resultat herauskommt - also eben gerade, dass
    > man "nicht" darauf achten muss, dass es zusammen läuft, weil das bei OOP
    > kein Problem sei es zusammen lauffähig zu machen.

    Was genau hat jetzt OOP bitte damit zu tun? Es geht hier um eine vollkommen andere Sache, die Sprache ist dabei egal, es könnte auch schlicht Assembler sein. Auch dein Verständnis von OOP ist ziemlich... komisch.

    Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

  6. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: Cerdo 25.05.20 - 09:54

    flikens schrieb:
    --------------------------------------------------------------------------------
    > Ist das wirklich so? Ich dachte wenn mehr Programmierer zur Verfügung
    > stehen, können die sich auf unterschiedliche Bereich fokussieren und somit
    > parallel entwickeln.

    Wenn alles modularisiert ist, die Module und Schnittstellen klar definiert sind, dann ja.
    In der Praxis wird der Entwurf aber meist erst beim Coding nebenbei erstellt. Das kostet mehr Zeit, als es vorher zu machen und ist Fehleranfällig, aber das verstehen Projektleiter nur selten.

  7. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: abdul el alamein 25.05.20 - 12:53

    Ich würde diesem widersprechen.

    Um die Schnittstellen "perfekt" zu designen, muss man die Software schon gebaut haben (OT: Wenn ich Software baue, die ich schon mal gebaut habe, sollte ich mich als Software-Entwickler fragen ob ich evtl. einen anderen Job machen sollte). Für etwas neues muss man sich ständig mit den anderen abstimmen - und genau das skaliert einfach nicht so gut. Idealerweise würde man Schnittstellendesign auf Sprint-Länge im Voraus machen - dann kann man innerhalb des Sprints damit arbeiten. In der Praxis funktioniert das nur für einfache APIs und wenige Teams. Ich benutze hier das Wort API stellvertetend für alle Arten der Modularisierung und externen Abhängigkeiten.

    Sobald du mehr als 10 Teams hast, musst du einen riesegen Vorlauf haben was Design angeht, es folgt die Spezialisierung auf Design und Feedback-Loops werden länger. Schon bald ist es so, dass selbst wenn ich als Entwickler eine API-Verbesserung haben will, das einfach zu lange dauert und ich es ganz sein lasse. Gegenmodell dazu wären das "google"-Modell, wo der gesamte Source-Code des Unternehmens in _einem_ Repo steckt und jeder alles ändern kann. Das braucht Unmengen Testautomatisierung und funktioniert nur wenn du ausschließlich sehr talentierte Leute hast. Das wird bei VW nicht gehen.

  8. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: abdul el alamein 25.05.20 - 12:58

    1. Bin komplett einverstanden, das Dev-Teams sollte IMHO sowieso am Produktdesign beteiligt sein, sonst kommt nur Bullshit bei raus (außer du hast sehr technikaffine Designer, aber selbst dann brauchst du eine gute Feedback-Schleife)

    2. Architektur ist IMHO kein technisches Problem, sondern ein menschliches. Es hat sicher einen technischen "Kern". Aber die Challenge ist doch, wie kann ich dafür sorgen, dass: a) ein gutes Architektur-Design entsteht? und b) dieses Design von einem Projekt mit vielen Teams und vielen Entwicklern umgesetzt wird inkl. Änderungen. Ein technisches Problem ließe sich mit einer technischen Lösung lösen. Für Architektur hilft aber nur reden, reden, reden...

  9. Re: Wie skaliert und beschleunigt man Software-Entwicklung?

    Autor: Clown 27.05.20 - 09:11

    Eine Schnittstelle muss ja nicht direkt perfekt sein (kann mE auch gar nicht). Es geht ja eher darum grobe Schnitzer von Anfang an zu vermeiden.

    "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s

  1. Thema

Neues Thema Ansicht wechseln


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. Viega Holding GmbH & Co. KG, Attendorn
  2. Limbach Gruppe SE, Heidelberg
  3. Hays AG, Illertissen
  4. Forschungszentrum Jülich GmbH, Jülich

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 46,99€
  2. (-91%) 1,20€
  3. 29,32€ (PS4), 29,99€ (Xbox One)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Kumpan im Test: Aussehen von gestern, Technik von morgen
Kumpan im Test
Aussehen von gestern, Technik von morgen

Mit der Marke Kumpan Electric wollen drei Brüder aus Remagen den Markt für elektrische Roller erobern. Sie setzen auf den Look der deutschen Wirtschaftswunderjahre, wir haben ein Modell getestet.
Ein Praxistest von Dirk Kunde

  1. Venturi Wattman Rekordversuch mit elektrischem Motorrad mit Trockeneis
  2. Mobility Swapfiets testet Elektroroller im Abo
  3. Elektromobilität Volabo baut Niedrigspannungsmotor in Serie

HTTPS/TLS: Zwischenzertifikate von Tausenden Webseiten fehlerhaft
HTTPS/TLS
Zwischenzertifikate von Tausenden Webseiten fehlerhaft

Viele Webseiten müssen ihre Zertifikate tauschen, da sie von Zwischenzertifikaten ausgestellt wurden, die ein Sicherheitsrisiko darstellen.
Von Hanno Böck

  1. Nach Safari Chrome und Firefox wollen nur noch einjährige Zertifikate
  2. Sicherheitslücke GnuTLS setzt Session-Keys auf null
  3. Sectigo Abgelaufenes Root-Zertifikat entfacht Ärger

Threefold: Die Idee vom dezentralen Peer-to-Peer-Internet
Threefold
Die Idee vom dezentralen Peer-to-Peer-Internet

Wie mit Blockchain, autonomem Ressourcenmanagement und verteilter Infrastruktur ein gerechteres Internet entstehen soll.
Von Boris Mayer

  1. Circulor Volvo kämpft per Blockchain gegen Warlords und Kinderarbeit
  2. Hamsterkäufe App soll per Blockchain Klopapiermangel vorbeugen