1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › IT-Branche: Warum es so…

Der wahre Grund...

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Der wahre Grund...

    Autor: dvstm 29.04.21 - 12:15

    Es gibt garantiert sehr viele, sehr schlechte Entwickler. Der Artikel ignoriert allerdings wesentliche Faktoren komplett (edit: oder auch nicht...):

    * unrealistische Vorstellungen
    * schlechtes Steakholdermanagement
    * schlechte Anforderungsanalyse
    * wahnwitzige Zeitpläne
    * ...

    Meiner Erfahrung nach scheitern die meisten Probleme am Management und nicht unbedingt an den Entwicklern, die dann die Suppe ausbaden dürfen.



    1 mal bearbeitet, zuletzt am 29.04.21 12:28 durch dvstm.

  2. Re: Der wahre Grund...

    Autor: Jalousie 29.04.21 - 12:21

    Deine Anmerkung steht im letzten Absatz des Artikels.

    Wahrscheinlich gibt es auch viele schlechte Software, weil das Lastenheft nicht bis zu Ende gelesen wird. ;-)))

  3. Re: Der wahre Grund...

    Autor: Der schwarze Ritter 29.04.21 - 12:21

    Das ist der Punkt. Die Software ist nicht schlecht, weil der Programmierer schlecht ist, sondern weil er nicht die Zeit hatte, sie gut zu machen. Klar, es gibt genug Programmierer, die auch mit ausreichend Zeit nur schlechte Software entwickeln. Aber leider gibt es auch viele gute Programmierer, die mit völlig bekloppten Zeitplänen konfrontiert werden und daher irgendwo Abstriche machen müssen - und sei es auch "nur" in der QS bzw. der Behebung von Problemen, die in der QS aufgetaucht sind. Oft genug hört man da "Ach, das fixen wir später, hauptsache, das läuft erst mal". Und leider bleibt dieser Status dann über Monate und Jahre, bis mal jemand darauf aufmerksam wird, der nichts Gutes vorhat.

    Der letzte Absatz beschreibt das ja schon.



    1 mal bearbeitet, zuletzt am 29.04.21 12:22 durch Der schwarze Ritter.

  4. Re: Der wahre Grund...

    Autor: dvstm 29.04.21 - 12:23

    Daran ist die schlechte Software von golem schuld! Eine gute Seite hätte mir angezeigt, dass ich den Artikel noch nicht fertig gelesen habe!!! :)



    1 mal bearbeitet, zuletzt am 29.04.21 12:24 durch dvstm.

  5. Zu weites Feld

    Autor: janoP 29.04.21 - 12:44

    "Softwareentwickler" ist kein Feld der Expertise. Das ist wie "Hersteller von Dingen".

    Wenn es nur "Hersteller von Dingen"-Ausbildungen und "Hersteller von Dingen"-Studiengänge gäb, würden unsere Gießkannen, Wolkenkratzer und Brücken nicht anders aussehen als unsere Software.

    Das Problem ist, dass Software eine ganze Welt ist, mit der man komplett unterschiedliche Konstrukte bauen kann. Dafür sind unterschiedliche Fähigkeiten erforderlich. Wer (client-seitige) Web-Entwicklung macht, muss sich mit Accessibility auskennen, mit unterschiedlichen Eingabe- und Ausgabemethoden (Tastaturen, Mäuse, Touchpads, Bildschirme, Screenreader, Braille-Zeilen), mit Farblehre und Konstrasten, UX-Patterns und dem psychologischen Aspekt von UI, aber auch mit HTML, JavaScript, JSON, Rendering-Engines von Browsern, Client Storage, Service Worker, Caching, HTTP-Protokoll, usw. Ja, "Programmieren" ist die Grundvoraussetzung - das ist aber so, wie "das Benutzen der Hände" die Grudvoraussetzung für das Herstellen von Dingen ist. Was man damit macht, unterliegt komplett eigenen Feldern der Expertise. Wer seine Hände benutzen kann, braucht noch mal mehr Expertise, um zu wissen, wie man eine gute Gießkanne baut.

    Völlig andere Dinge muss man können, wenn man man z. B. auf der Backend-Seite mit Datenbanken arbeitet. DBMS, SQL, SQL Injection, API-Design, Validierung, alles mögliche.

    Wenn man hingegen Desktop-Anwendungen mit einem GUI-Framework entwickelt, muss man wieder ganz andere Sachen können.

    Und jetzt stell dir mal vor, du machst etwas ganz spezielles, entwickelst eine Browser-Engine z. B.. Wer, der "programmieren" kann, kann das? Nur jemand, der sich explizit damit beschäftigt hat. Klar, die Grundlagen, Grammatiken, Lexer, Parser, haben wir alle irgendwann mal im Informatikstudium gehört, aber wir brauchen uns nicht einbilden, dass wir mit dem Wissen bei Mozilla an Gecko schrauben könnten.

  6. Re: Der wahre Grund...

    Autor: ubuntu_user 29.04.21 - 13:18

    dvstm schrieb:
    --------------------------------------------------------------------------------
    > Es gibt garantiert sehr viele, sehr schlechte Entwickler. Der Artikel
    > ignoriert allerdings wesentliche Faktoren komplett (edit: oder auch
    > nicht...):

    das Problem sind aber auch keine schlechten Entwickler. Selbst wenn es schlechte Entwickler gibt muss man die ja nicht an kritische Sachen ranlassen.



    > * unrealistische Vorstellungen
    > * schlechtes Steakholdermanagement
    > * schlechte Anforderungsanalyse
    > * wahnwitzige Zeitpläne
    > * ...
    genau

  7. Re: Der wahre Grund...

    Autor: nolivier 29.04.21 - 13:38

    Ein großer Punkt ist auch oft das Verständniss der Anforderung in ein Programm zu überführen.
    Der beste Programmierer wird an einer BH-SW scheitern wenn er keine Ahnung und kein Verständniss von Buchhaltung hat.
    Ein ebenso großes Problem ist dass das Leistungsheft oft von Personen erstellt wird die keine Anhnung von Arbeitsabläufen haben. Dann wird herum gedocktert.
    Und dann haben wir noch ein ganz schönes: Nachträgliche Änderungen, Erweiterungen.
    Besonders Beispiel: Windows - das ist noch Code drinnen, den sich keiner rausnehmen traut, weil keiner weiß was passiert obwohl dieser noch aus der Zeit stammt, wo, naja, noch in Stein gemeißelt wurde ;-)

    Software ist wie ein Auto, nur wenn ich da Reifen wechsel muss ich das gesamte Fahrzeug prüfen. Was schier kaum machbar ist. Finanziell genaus wie Manpower und Zeit.

    n.Olivier
    ---

  8. Re: Zu weites Feld

    Autor: Der schwarze Ritter 29.04.21 - 14:49

    Spezialisierung hat man irgendwann überall, das ist kein Problem im Softwaresektor.

    Aber eine Sensibilisierung für Qualität hat erst mal nichts mit der Spezialisierung zu tun. Ganz viel davon ist Bequemlichkeit, einiges auch mangelnde Zeit und fehlendes Geld. Aber ich kenne leider genügend Entwickler, die da einfach kein Gespür dafür haben, was für gute Software wichtig ist. Ein ganz toller Fall war einer, der meinte, er braucht keinen Debugger, weil er lieber etwas länger überlegt und den Code dann direkt von Beginn an richtig schreibt. Darum reicht im ein Texteditor zum Programmieren und fertig. Mit solchen selbstüberschätzenden Helden gewinnt man halt einfach auch nichts, ganz egal, wie nun die genaue Bezeichnung des Berufs ist. ;)

  9. Re: Der wahre Grund...

    Autor: dummzeuch 29.04.21 - 18:20

    dvstm schrieb:
    --------------------------------------------------------------------------------
    > * schlechtes Steakholdermanagement

    Ich will ein Steak nicht nur halten, ich will es essen!

  10. Re: Der wahre Grund...

    Autor: dvstm 29.04.21 - 18:55

    Ich denke am Ende läufts halt oft drauf raus: die die Ahnung haben, haben oft nicht die Skills die Probleme/Lösungen zu kommunizieren. Die die die Entscheidungen treffen wollen nur paar Wins für ihr nächstes Assignment oder werden nicht entsprechend abgeholt. Dazwischen hat man paar mittlere Manager die zerieben werden. Am Ende hat man den Salat. Paar gehn, paar kommen und es geht von vorne los - hoffentlich mit paar Learnings. :)

  11. Re: Der wahre Grund...

    Autor: ThorstenMUC 29.04.21 - 19:26

    Der schwarze Ritter schrieb:
    --------------------------------------------------------------------------------
    > Klar, es gibt genug Programmierer, die auch mit ausreichend Zeit nur
    > schlechte Software entwickeln. Aber leider gibt es auch viele gute
    > Programmierer, die mit völlig bekloppten Zeitplänen konfrontiert werden und
    > daher irgendwo Abstriche machen müssen

    Es gibt beides... ich bin auf der Zeitplaner-Seite und versuche den Plan realistisch und die Qualität hoch zu halten.
    Aber hier kommt halt auch noch das Menschliche mit dazu - ich kann selbst als Programmier-Laie nur schwer einschätzen, wie lange eine gute Entwicklung braucht.
    Und es ist dann mehr Sozialkompetenz, als Planungskompetenz notwendig zu erkennen, dass der wortkarge Entwickler, der sich nach dem Planungsmeeting ne Palette Red-Bull bestellt mir eigentlich damit sagen will, dass er mehr Zeit bräuchte ;-)

    Der Kunde wird immer mehr in kürzerer Zeit wollen... es braucht halt auch jemanden, der ihn in verständlichen Worten auf den Boden der Tatsachen holt.

    Manche "dark-mode Entwickler" (neben dem Energy-Drink mein erstes Indiz, dass ich in der Kommunikation in den Geek-modus schalten sollte) sind Klasse - solange man eine "Translation-Layer" zwischen ihnen und den Stakeholdern einziehen kann.

  12. Re: Zu weites Feld

    Autor: Dakkaron 29.04.21 - 19:41

    Der schwarze Ritter schrieb:
    --------------------------------------------------------------------------------
    > Spezialisierung hat man irgendwann überall, das ist kein Problem im
    > Softwaresektor.
    >
    > Aber eine Sensibilisierung für Qualität hat erst mal nichts mit der
    > Spezialisierung zu tun. Ganz viel davon ist Bequemlichkeit, einiges auch
    > mangelnde Zeit und fehlendes Geld. Aber ich kenne leider genügend
    > Entwickler, die da einfach kein Gespür dafür haben, was für gute Software
    > wichtig ist. Ein ganz toller Fall war einer, der meinte, er braucht keinen
    > Debugger, weil er lieber etwas länger überlegt und den Code dann direkt von
    > Beginn an richtig schreibt. Darum reicht im ein Texteditor zum
    > Programmieren und fertig. Mit solchen selbstüberschätzenden Helden gewinnt
    > man halt einfach auch nichts, ganz egal, wie nun die genaue Bezeichnung des
    > Berufs ist. ;)


    Aber das große Problem, dass der OP angesprochen hat, ist ja gerade, dass es diese Spezialisierungen nicht wirklich gibt. Ich habe letztens den Job gewechselt. Was mir ausnahmslos in jedem Job-Interview gesagt wurde war, dass man nicht einen Backend-Spezialisten sucht, sondern bitte jeder im Team Fullstack-Entwickler sein muss, bestenfalls noch mit einem Fokus auf dem Backend.

    Stell dir mal vor, man möchte bei einem Fahrzeughersteller anfangen, und der sagt dann "Wir suchen keinen Innenraumdesigner für das Fahrzeug, wir wollen lieber Full-Vehicle-Designer, die vom Motor bis zur Farbgebung des Innenraums alles designen können. Und das bitte nicht nur bei PKWs, sondern auch bei amphibischen Panzern."

    Aktuell arbeite ich zusammen mit einem Team aus C#/Windows-Entwicklern an einem Java/Linux-Projekt, welches wir von einem externen Team aus Indien geerbt haben. Und dann wundert sich die Chefetage, dass die Issues (nach einem Monat Einarbeitungszeit) noch immer so lang dauern.

    Und wenn es nur die Sprache und das OS wär, dann wär das noch nett. Wir müssen uns auch noch in mehrere selbstgebastelte (und freilich undokumentierte) Frameworks einarbeiten und aben uns auch eine CI/CD-Pipeline aufziehen müssen (selbstverständlich ohne Spezialisten im Team).

  13. Re: Zu weites Feld

    Autor: andkleves 29.04.21 - 19:47

    > Und wenn es nur die Sprache und das OS wär, dann wär das noch nett. Wir
    > müssen uns auch noch in mehrere selbstgebastelte (und freilich
    > undokumentierte) Frameworks einarbeiten und aben uns auch eine
    > CI/CD-Pipeline aufziehen müssen (selbstverständlich ohne Spezialisten im
    > Team).

    Ist nicht gerade die CI/CD Pipeline ein guter Ansatz, um auch von mittelmäßigen Programmieren dann doch gute Code-Qualität zu erhalten? Schon weil man damit sicherstellt, dass damit nicht jemand durch Seiteneffekte altes wieder kaputt macht?

    Dass jeder Experte für alles sein soll, ist natürlich auch quatsch - dazu muss man halt im Team arbeiten. Da haben wir bei meinem Arbeitgeber ganz gute Erfahrungen mit Scrum oder auch skaliertem Scrum.



    2 mal bearbeitet, zuletzt am 29.04.21 19:48 durch andkleves.

  14. Re: Zu weites Feld

    Autor: Mr_Kanistr 29.04.21 - 19:53

    Genau, Sie stellen das eigentliche Problem dar. Zumal Fullstack nicht Fullstack ist. In einem Projekt suchen die AG's einen mit React-Erfahrung im FE und Java / Springboot im BE. Ein anderes Projekt will Angular und node.js. Ein anderes Team meint, dass klassisches JS kacke ist und setzt auf next.js und ein paar early adaptor fragen sich, wieso man noch mit node.js arbeitet, wenn es doch auch deno.js gibt. Zusätzlich gibt es dann die Legacy-Projekte, die immer noch mit JQuery und Extjs zusammengebastelt wurden. Ich habe noch gar nicht von Symfony, Go oder ... Flutter angefangen. ASP.net wurde ja schon erwähnt. Viel Spaß dabei, diese ganzen Sprachen (und die dazugehörigen Frameworks) auf dem Artikel genannten "Master"-niveau zu kennen. Übrigens: Wie viele sicherlich wissen, wartet der nächste Hype schon mit WebAssembly.

    Musste letztens noch jemanden darüber aufklären, dass 80% der Entwickler im Web-Umfeld (egal ob studiert oder nicht) möglicherweise noch nie Mini-Spiele mit WebGL zusammengeschraubt haben. Kann man das alles lernen? Ja, aber wer will gerne unbezahlt für den Arbeitgeber am WE noch 100% in Weiterbildung investieren, ohne einen Euro dafür zu kriegen? Da spiele ich maximal mit meinen privaten Sachen rum.



    1 mal bearbeitet, zuletzt am 29.04.21 19:54 durch Mr_Kanistr.

  15. Re: Der wahre Grund...

    Autor: interlingueX 29.04.21 - 23:18

    dummzeuch schrieb:
    --------------------------------------------------------------------------------
    > dvstm schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > * schlechtes Steakholdermanagement
    >
    > Ich will ein Steak nicht nur halten, ich will es essen!

    Ob Grillzange oder Investor – in beiden Fällen kann man sich bei falscher Handhabung die Finger verbrennen. Allerdings ist es eher zu verschmerzen, wenn dir das Steak entgleitet, als wenn dich der Investor fallen lässt.

    ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
    Also, ich bin Generation A. Trends muss man setzen, bevor es zu spät ist.

  16. Re: Der wahre Grund...

    Autor: deisi 30.04.21 - 00:22

    Was mich immer stört, sind die zwanghaften Vergleiche zwischen Software und physischen Dingen. Warum sollte Softwareentwicklung etwas mit Brückenbau gemein haben? Das sind doch fundamental verschiedene Dinge. Vielleicht kann das eine von dem anderen lernen, aber Verständnis erlangt man durch solche Vergleiche nicht.

    Ich stelle mir gerade vor, wie git in der realen Welt aussehen würde. Git wäre quasi eine übermächtige Zeitmaschiene, die die gesamte Realität umändern kann. Man könnte ganz wunderbar absurde dinge mit dieser Git-Maschiene machen. Einfach eine Brücke bauen, und wenn sie einstürzt, einen alten commit wieder herstellen. Zack bum als wäre nix gewesen. Wie unsere Brücken dann wohl aussehen würden....

    Oder Ansible für Häuser. Entwirft man ein Haus, und schwups kommen aber Millionen hinten raus und wenn man ein neues Fenster will, dann baut man lieber gleich das ganze Haus nochmal neu auf und fügt erst dann das Fenster hinzu.

    Das ist alles sehr amüsant und trifft den Kern des Problems nicht viel schlechter als dieser Artikel.

  17. Re: Der wahre Grund...

    Autor: Hansi 30.04.21 - 01:43

    Jalousie schrieb:
    --------------------------------------------------------------------------------
    > Deine Anmerkung steht im letzten Absatz des Artikels.
    >
    Ein Artikel über 3 Seiten und am Ende zwei, die vermutlich nach Kritik entstanden sind, sollen es richten?

    Und auch da fehlen noch einige Punkte.

  18. Re: Der wahre Grund...

    Autor: Dakkaron 30.04.21 - 04:59

    Gute Arbeit, wenn das funktioniert.

    Hab es leider viel zu oft erlebt, dass der Projektleiter fragt, "Geht das in drei Sprints?", Das Team antwortet "Nein, wir brauchen mindestens 5, eher 7" und der Projektleiter dann sagt, "OK, ihr habt 3 Sprints Zeit".

    Oder auf "Mit ganz arg viel Glück könnte es sich in 2 Sprints ausgehen" - "Sehr gut, das heißt, es ist möglich in 2 Sprints".

  19. Re: Der wahre Grund...

    Autor: marsupilami72 30.04.21 - 09:59

    Jalousie schrieb:
    --------------------------------------------------------------------------------
    > Wahrscheinlich gibt es auch viele schlechte Software, weil das Lastenheft
    > nicht bis zu Ende gelesen wird. ;-)))

    M.E. gibt es in erster Linie schlechte Software, weil das Lastenheft nicht zu Ende geschrieben wurde ;)

  20. Re: Zu weites Feld

    Autor: mnementh 30.04.21 - 11:04

    andkleves schrieb:
    --------------------------------------------------------------------------------
    > > Und wenn es nur die Sprache und das OS wär, dann wär das noch nett. Wir
    > > müssen uns auch noch in mehrere selbstgebastelte (und freilich
    > > undokumentierte) Frameworks einarbeiten und aben uns auch eine
    > > CI/CD-Pipeline aufziehen müssen (selbstverständlich ohne Spezialisten im
    > > Team).
    >
    > Ist nicht gerade die CI/CD Pipeline ein guter Ansatz, um auch von
    > mittelmäßigen Programmieren dann doch gute Code-Qualität zu erhalten? Schon
    > weil man damit sicherstellt, dass damit nicht jemand durch Seiteneffekte
    > altes wieder kaputt macht?
    >
    Naja, Continuous Integration ist schon gut, aber es führt auch nur an Tests durch, was an Tests drinsteckt in dem Code. Also wenn man keine Tests hat, dann stellt Continuous Integration nur fest, dass es kompiliert und wenn man eine interpretierte Sprache benutzt nicht mal das.

    Continuous Deployment halte ich für gefährlich, produktiv sollten nur abgehangene Versionen ausgerollt werden. Aber CD kann auch Continuous Delivery bedeuten, was meinem Verstädnis nach bedeutet, dass Dinge automatisch auf einem Testserver ausgerollt werden. Das ist OK, aber kein Wundermittel Bugs zu finden. Es kann aber sehr hilfreich für ein Testteam sein und als Entwickler kann man dem Kunden auch mal ganz schnell den aktuellen Stand der Entwicklung zeigen.

    Beides federt allein nicht gegen schlechten Code ab.

  1. Thema
  1. 1
  2. 2

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. Duisburger Versorgungs- und Verkehrsgesellschaft mbH, Duisburg
  2. Haufe Group, Freiburg
  3. KfW Bankengruppe, Frankfurt am Main
  4. dSPACE GmbH, Paderborn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 21€
  2. 19,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme