No video

Softwareentwicklung ist viel zu teuer?! // deutsch

  Рет қаралды 15,980

the native web GmbH

the native web GmbH

Күн бұрын

Пікірлер: 131
@UweGrimm
@UweGrimm Жыл бұрын
Genialer Vortrag, vielen Dank. Nicht nur, dass das Deutschniveau vom feinsten ist, du hast auch vollkommen Recht. Da können sich wahrscheinlich viele Firmen ein Beispiel nehmen. :-)
@zickzack987
@zickzack987 Жыл бұрын
Einen wesentlichen Punkt hast du vergessen. Softwareentwickler die einfach grottenschlecht sind. Und das sind heutzutage die meisten.
@makusgast5191
@makusgast5191 Жыл бұрын
Meiner Meinung nach liegt es an sehr vielen Dingen. Zum einen die ewige Entscheidungsfaulheit ob man jetzt agil sein will oder nicht und irgendwelche Übergangsprozesse verwendet, die schon in ihrer Natur hinderlich sind. Dann werden Termine von Entwicklern teilweise auch mit nutzlosen Terminen zugeballert, in denen die Expertise von Entwicklern gar nicht gefordert ist und in welcher man die ach so teure Expertise auch lieber mit wichtigen Themen füllen könnte. Dann die Tatsache, dass viele Entscheidungen von Leuten getroffen werden, die eigentlich ein ganz anderes Kenntnisgebiet haben. Solche Entscheidungen haben dann ziemlichen Einfluss auf Qualität, Scope usw. Aus klassischer Managersicht ist halt nunmal das Ziel gewisse Kennzahlen nach oben bzw. Unten zu treiben. Es fehlt aber oft einfach an Metriken, die die technischen Probleme oder Chancen beleuchten. Somit ist aus Managementsicht alles fein, beim genaueren hinsehen (und mit den nötigen Kenntnissen) sieht es dann aber doch anders aus. Aber wer möchte schon freiwillig so etwas nach oben kommunizieren, wenn es förderlicher für die eigene Karriere ist zu sagen das alles tutti ist. Das demotiviert dann auch die Entwickler und wenn man die Kreativität eines Entwickler als Ressource betrachtet, die wertvoll ist und genutzt werden kann. Schafft man es als Unternehmen/Konzern nicht auch solche Ressourcen aus seinen Entwicklern (sowie jedem Mitarbeiter) herauszukizeln, ist das meiner Meinung nach auch Verschwendung und kostet letzten Endes auch Geld. Ich könnte mich darüber echt stundenlang aufregen. 🥲
@RogerFrei
@RogerFrei Жыл бұрын
Vielen Dank. Du sprichst mir aus dem Herzen. Ich bin freischaffend und kenne beides. Kunden die den Entwicklungsprozess kennen, leben und sauber eine Analyse, eine Strategie, ein Konzept und einen Plan erstellen bevor sie mit Tippen anfangen. Und jene die denken sie wüssten ja wie das Produkt aussehen sollte und entgegen aller Warnungen und Bitten darauf bestehen, dass man sofort anfängt Code einzutippen. Und jetzt dürft ihr raten, welche der beiden Kundengruppen sich permanent über Preis und Termin beschwert. Mein liebster Satz: ja sie hätten hald gedacht das.......
@rolfspeer5403
@rolfspeer5403 Жыл бұрын
Mein Lieblingssatz ist: So schwer kann das doch nicht sein, dass die Anwendung [und dann kommen die Änderungswünsche]
@user-sd5rw9em2l
@user-sd5rw9em2l Жыл бұрын
Thema Outsourcing: man kann nur outsourcen was man selber beherrscht aber auf Grund von Personalressourcenmangel nicht zu 100% selbst leisten kann. Mit Outsourcing kann man dann 50-75% Aufwand abgeben. Wenn man Outsourcing falsch verwendet (das kann ich nicht selbst, das macht jemand extern billiger/schneller, da muss ich mich dann nicht selbst drum kümmern), dann ist das der Garant für ein Fehlschlag. Thema Qualität: man kann Qualität nur erhalten, aber nicht wieder herstellen. Muss man sie wieder herstellen, dann fängt man wieder von vorne an. Thema billiger: wenn man schon bei der Neuentwicklung billiger sein will, wo ist der Bezugspunkt bei der Preisreduktion ? Es gab doch kein vorheriges System, das man billiger machen kann als vorher. Erst das Nachfolgeprodukt kann billiger als das vorherige erstellt werden, da Vorarbeit und Wissen bereits aufgebaut wurde. Meist ist das eher synonym zu sehen zu: das Budget wurde willkürlich festgelegt und wurde als oberstes Entwicklungsziel gesetzt. Thema zu teuer: wenn das zu entwickelnde Produkt nicht genug Geld abwerfen wird um die Entwicklung zu finanzieren, dann darf man das Produkt nicht entwickeln. Wenn nach jedem gerissenen Termin/ milestone / Releasedatum wieder Budget nachgeschossen werden kann, war jedes begrenztes Budget (Geld als auch Zeit) nur ein Versuch, das Personal unter Druck zu setzen um Mehrleistung auszupressen. Thema Schulung: wenn Programmierer zu lange brauchen für eine Aufgabe bei einer Neuentwicklung : schon mal an Weiterbildung gedacht/Budget dafür vorgesehen ? Wenn man neue Produkte entwickelt sind vielleicht nicht alle benötigten Kenntnisse bereits vorhanden ? Werden diese Kenntnisse durch "Learning while Doing" im Projekt uneffektiv ohne Tutor erarbeitet ? Ineffizienz ist ein Kostentreiber.
@anion21
@anion21 Жыл бұрын
Du sprichst mir aus der Seele. Viele sehen nur Stundensätze von Entwicklern und denken sich dann: Das sind die Kosten, die entstehen. Das ist teuer. Dass aber jede Änderung der Anforderung, die zwischendurch reinkommt, und jede Spezifikationsungenauigkeit, über die man sich dann hinterher um so mehr Gedanken machen muss, dazu führt, dass Software-Entwicklung viel länger dauert als es nötig gewesen wäre und dass das viel entscheidendere Faktoren sind, sehen viele Nicht-Entwickler leider nicht. Und dass das besser wird, wenn man das berücksichtigt, was du in diesem Video erzählt hast, wissen viele Nicht-Entwickler auch nicht. Aber hinterher über zu hohe Kosten beschweren tun sie sich oft trotzdem.
@johnjohnson7500
@johnjohnson7500 Жыл бұрын
Das ziellose Vorgehen ist leider etwas, was ich - durch das Unternehmen für das ich arbeite - zu gut kenne. Mit unausgereifter Low-Code Software hatten wir auch schon zu tun. Ich stimme deinen genannten Punkten zu 100% zu. Außerdem wieder vielen Dank für das Video :)
@MeinErsterKanal
@MeinErsterKanal Жыл бұрын
Als Senior Entwickler stimme ich dir zu 100% zu.
@klausmeucht6397
@klausmeucht6397 Жыл бұрын
Danke für dieses Video. Das wesentliche an Softwareentwicklung ist dass man immer wieder neue Dinge entwickelt. Wenn Sie Kopfweh haben und zum Arzt gehen, wissen Sie auch nicht ob Sie einfach einen Rausch ausschlafen müssen, oder ein Gehirntumor die Ursache ist. Man kann erst vernünftig schätzen und planen, wenn man die Problematik verstanden hat. Kommt man als Entwickler in ein neues Projekt, ist das Fachgebiet meistens neu, die Arbeitsumgebung neu und die Kultur des Unternehmens neu. Die Manager wollen aber klare Aussagen und Pläne und Zeitaufwände. Mein Vorgesetzter hat von mir mal allen Ernstes "Design bei Cost" verlangt. Ich soll nicht mehr und nicht weniger Zeit in den Design stecken, wieviel Geld gerade vorgesehen war. Ist die Lösung des Problems einfach ausschlafen, dann sendet man eine dicke Rechnung obwohl man nichts gemacht hat. Handelt es sich um einen Gehirntumor wird das Problem weitgehend ignoriert und der Patient verstirbt mit Sicherheit.
@helw7
@helw7 Жыл бұрын
Ich denk eine gute Mischung macht es aus, denn als Unternehmer ist es teilweise auch notwendig, Dinge erst mal auszuprobieren, bevor man etwas bauen lässt, das zwar technisch gut funktioniert, aber sich dann so nicht gut genug verkaufen lässt. Wenn man ausschließlich auf technisch saubere Lösungen setzt, könnte das unter Umständen auch der wirtschaftliche Ruin für ein Unternehmen sein. Deshalb würde ich als Unternehmer nur dort auf besonders saubere Lösungen setzen, wo ich weiß, dass ich den eingeschlagenen Weg auch langfristig fortsetzen will.
@Leon-cm4uk
@Leon-cm4uk Жыл бұрын
Das ist echt ein goldwertes Video, welches es genau auf den Punkt bringt!
@bytegamemakermagazin
@bytegamemakermagazin Жыл бұрын
Stimme Dir zu 100% zu! Hinzu kommt, dass man seit Jahren dem sog. Nachwuchs erzählt, dass man eigentlich nicht mehr programmieren lernen müsste. Besonders dieses Jahr habe ich dank ChatGPT und Konsorten unzählige solcher Diskussionen führen dürfen. "He, bald brauchen wir keine Programmierer mehr." Fragt sich nur, wer den Mist fixen soll, sobald die Maschine Fehler produziert, die sie selbst nicht erkennt. Derzeit ist das ja der Normalzustand.
@AndreNitschke
@AndreNitschke Жыл бұрын
Oder man verbiegt Software mit sogenannten Plugins zu "Lösungen" für die sie nicht gemacht sind. Wordpress ist ja das Allheilmittel für alles 😅. Du sprichst uns aus der Seele.
@brennsuppa
@brennsuppa Жыл бұрын
Ich arbeite als Requirement Engineer und unser Ziel ist es genau, einen realistischen Scope auszuhandeln und ein gemeinsames Bild auf die Software zu bekommen. Das vermeidet massiv kurzfristige Änderungen, die während dem Prozess vorkommen können.
@kleinebudde335
@kleinebudde335 11 ай бұрын
Sehr gutes Video. Ich gehe leider davon aus, dass diese Videos hauptsächlich von Softwareentwicklern gesehen werden, was ja leider Teil des Problems ist. Meine mittlerweile langjährige Erfahrung als Softwareentwickler ist auch, dass die Probleme vor allem in der Kommunikation liegen.
@joergfoerster8043
@joergfoerster8043 Жыл бұрын
Da Software sich leicht vervielfältigen lässt, bestehen große Kostenunterschiede zwischen massenhaft genutzter Software und Individualsoftware für einen kleinen Benutzerkreis. Manchmal ist Software auch kostenlos. Da setzt mit den Erwartungsrahmen. Im Unterbewusstsein mancher Menschen könnte das "soft" mit weich, leicht und preiswert anpassbar in Verbindung gebracht werden. Andere Bezeichnungen werden kaum verwendet. Trotzdem mache ich mal Brainstorming: Automatengesetze, maschinelle Vorgehensweise, Automatenregeln, Denkware, Ablaufware, Prozedurenbündel, Verarbeitungsmethoden, Rechenvorschrift statt Software. Weitere Ideen wüsste ich gerne.
@_gk_7407
@_gk_7407 6 ай бұрын
😊 👍🏼 Sehr gut erklärt … Meine Predigt, danke. 🙏🏼 13:33
@thenativeweb
@thenativeweb 6 ай бұрын
Vielen Dank 😊
@marinaegner
@marinaegner Жыл бұрын
Tolles aufschlussreiches Video! 😃 So ein vermeintlich zielloses Vorgehen in Firmen, konnte ich auch schon deutlich beobachten und es hat, wie du schon sagst, tendenziell vieles eher schlechter gemacht, als besser.
@thenativeweb
@thenativeweb Жыл бұрын
[gr] Vielen Dank für Deinen Kommentar! Was ich an dem ganzen Punkt ja immer nicht verstehe ist, warum eigentlich immer noch geglaubt wird, dass die im Video angesprochenen Maßnahmen (und ähnliche, da gibt's sicherlich noch mehr) eigentlich helfen würden, Kosten einzusparen. Aber vermutlich kann ich mir die Frage auch selbst beantworten: Weil diese Sicht und die daraus resultierenden Entscheidungen von Leuten getroffen werden, die selbst nicht aktiv in der Entwicklung sind. Das sind die gleichen Leute, die auch denken, wenn man Geld sparen möchte, wäre es eine gute Idee, Mitarbeiter:innen zu entlassen - aber das ist halt so schön einfach … Über kurz oder lang merken sie es dann aber in der Regel, nur ziehen die Unternehmen dann leider oft die falschen Konsequenzen …
@marinaegner
@marinaegner Жыл бұрын
@@thenativeweb ja definitiv! Sehe ich ganz genauso.
@No-no-no-no-nope
@No-no-no-no-nope Жыл бұрын
Bei unserem derzeitigen Projekt haben wir fünf Wochen Zeit für einen Prototypen. Statt alles sorgfältig zu planen, wird hektisch drauf los programmiert. Am Ende soll dann schnell ein fertiges Produkt daraus werden… Software muss man am Anfang nur gut planen, dann kann sie auch jeder im Team einfach programmieren und testen.
@sen-sha
@sen-sha Жыл бұрын
Haha, ja, und wenn der Prototype dann steht heißt es, na funktioniert doch schon fast. Dann ist es doch nicht mehr viel und das Produkt ist fertig!
@stmfotografie
@stmfotografie Жыл бұрын
​@@sen-shanichts hält so lang wie das Provisorium 😂
@wasauchimmer
@wasauchimmer Жыл бұрын
Sehr schön! Ist natürlich erstmal nichts neues, aber wunderbar zusammengefasst, Danke Golo! Bin aus vielen der genannten Gründe vor 13 Jahren aus dem Projektgeschäft in die Produktentwickling gewechselt. Habe festgestellt, dass diese ganzen Diskussionen mit den Menschen des Schlags "Das geht doch sehr einfach, ich habe ja auch mal Access programmiert" mir zuviel meiner Lebenszeit kosten. Bei der Produktentwicklung habe ich jetzt meine "Firewall" zu den Kunden nach aussen und darf mich nur mit den lösungsorientierten Menschen unterhalten :)
@valeridause
@valeridause Жыл бұрын
No-Code Entwickler! Das ist herrlich. Aber so treffend und richtig gesagt. Danke für das Video!
@pepperparkffm
@pepperparkffm 2 ай бұрын
Struktur und Qualitaet sind absolut wichtig. Aber eher nur fuer uns Entwickler. Die Entwicklung ansich steht auf den drei bekannten Saeulen in-time, in-quality, in-budget. Den Unternehmen geht es aber meistens dann doch eher um time-to-market. Ich selbst sehe das aehnlich und frage mich mittlerweile, ob viele Dinge nicht per se over-engineered werden. Der Kunde zahlt fuer das erste funktionale Produkt eine Summe X. Ende. Durch eine gute Struktur, Architektur und Qualitaet kann man Folgeauftraege (Features etc) sicher einfacher und schneller umsetzen. Aber ganz ehrlich, wen interessieren dann hoehere Kosten, falls man das nicht am Anfang gemacht hat? Dann zahlt der Kunde halt beim Feature 2 einen fetten Refactoring-Aufschlag mit, falls man wieder ins Geschaeft kommt. Ich finde, eine 'gute' Qualitaet ist absolut ausreichend. Dienstleister, die sich die beste Codequalitaet (> 95%) auf die Fahne schreiben, kann ich nicht mehr ernst nehmen. Wir sind im Business und nicht bei der NASA.
@inkognito5448
@inkognito5448 Жыл бұрын
Für mich klingt das Konzept der besseren und weitsichtigeren Planung nach der einzigen sinnvollen Lösung. Jeder halbwegs professionelle Unternehmer arbeitet genau so, branchenübergreifend. Man darf sich eben nicht von der Ungeduld der Kunden anstecken lassen…😅
@kevinpeters6274
@kevinpeters6274 Жыл бұрын
Danke für das Video. :) Ich stimme zu 100% zu, das ist genau das Problem, unter dem viele Projekte leiden. Toll, dass du alles mal zu zusammengefasst hast.
@N.A._McBee
@N.A._McBee 11 ай бұрын
Sehr vernünftige Zusammenfassung der Problematik! Habe ich alles selber erlebt, also, all dieses Negative. Aber ich fürchte, daß sich das niemals ändern wird. Ich sehe keinen Weg aus den aufgezeigten Dilemmata, Menschen sind einfach zu stur, zu egoistisch, zu borniert, zu ignorant, jedenfalls dann, wenn sie in Gruppen auftreten. Bei allen anspruchsvolleren Projekten sieht man das Problem, daß jeder dem anderen Gewerk reinquatscht, ohne Fachkenntnis zu besitzen, daß die Projektleitung ganz oben einfach mal eben die Grundlagen austauscht oder entscheidende Kenngrößen ändert. Siehe BER, siehe Stuttgart 21. Wenn die Projekte zu komplex und die Zahl der Beteiligten zu groß wird, oder auch die Zahl der beteiligten Interessensgruppen, wird alles zum Glücksspiel. Leider.
@marcusreinicke
@marcusreinicke Жыл бұрын
Golo, besser kann man es nicht beschreiben. Zusätzlich gibt es noch einen Punkt. „Das haben wir schon immer so gemacht“ und wir müssen schnell etwas implementieren, oder besser, das ändere ich mal eben beim Runterfahren. Entwicklung ist nicht nur coden, dazu gehört sehr viel mehr Gehirnschmalz und auch Fehler! Aber leider wird Qualität der Quantität unterstellt, was sehr viel Probleme macht. Die Softwareentropie nimmt seinen Lauf.
@sevensolutions77
@sevensolutions77 Жыл бұрын
Ich glaube das Kernthema sind steigende Erwartungen und die damit einhergehende steigende Komplexität von Software.
@wklenk
@wklenk Жыл бұрын
"Zielloses Vorgehen" würde ich nicht komplett unterschreiben. Wer in SW-Projekten die agile Bewegung der letzten Jahren nicht komplett ignoriert hat (z.B. Agiles Manifest), weiß genau, wie man Projekte mit Chance auf Erfolg durchführt, und was man unterlassen muss, um Projekte nicht gegen die Wand zu fahren und endlos teuer zu machen. Wir wissen, wie es geht, aber wir kriegen es in vielen Unternehmen einfach nicht umgesetzt. Es liegt an Machtstrukturen, Budget-Jahresplanung, Personalplanung, Organisationsstrukturen und noch vielem anderen mehr. Auch an einer Unternehmenkultur, in der niemand offen sagen darf, wenn Dinge Grütze sind und besser eingestampft werden sollten, oder dass das Management mit strategischen Entscheidungen einfach falsch liegt. Okay, hauptsächlich betrifft das wahrscheinlich eher größere mittelständische Unternehmen oder Behörden. Kleinere Unternehmen würden einfach viel schneller vor die Hunde gehen. Daher denke ich, kleinere Unternehmen oder spezialisierte SW-Dienstleister haben eher die Fähigkeit, Klartext zu reden und mit agilen Vorgehensweisen die Projektkosten in überschaubaren Grenzen zu halten.
@kiwibu
@kiwibu Жыл бұрын
Soziale Systeme sind komplex, damit ist SW-Entwicklung komplex und nur schwer kalkulierbar. Was ein gutes agiles Projekt, das schnell und effektiv und ergebnisorientiert arbeitet, zerstören kann, sind die Rahmenbedingungen durch die vielen Stakeholder u. a. dem Einkauf
@user-pc6yj7qn1z
@user-pc6yj7qn1z Жыл бұрын
Hi Golo, Superbeitrag. Ich kann nahezu allem so zustimmen. Wenn man mich fragt "Warum ist Software-Entwicklung so teuer?" sage ich immer: "Weil es ein soziales System ist." Gerade bei produzierenden Unternehmen, wo es um Skaleneffekte in der Produktion und Mengenrabatte im Einkauf geht, ist das kein No-Brainer. Ich wurde ernsthaft einmal gefragt, warum wir denn nicht billiger werden, weil wir gegenüber dem Jahresanfang mittlerweile 10 Entwickler mehr beschäftigen - wo ist also der Mengenrabatt? Meine Antwort war etwas provokant: Wir werden teurer, weil das soziale System mit jedem zusätzlichen Menschen komplexer wird, d.h. das Programm- und Portfolio-Management mit Zielschärfung und Ausrichtung der Teams muss mitskalieren. Auf Arbeitsebene wurde es verstanden, gegenüber dem Top Management war es schwerer vermittelbar.
@ADieringer
@ADieringer Жыл бұрын
Ein Overhead an Projektmanagern mit vierzig Meetings in der Woche, weiß genau, was er macht 😂. Leider schon so oft erlebt, dass Vision zwar schön ist, das Ziel aber nicht wirklich definiert werden kann. Dann kommen Projektmanager, die keine Ahnung von Vision und Ziel haben, nicht mit Entwicklern sprechen können, das Sie diese einfach nicht verstehen, was die brauchen. Dann wird es einfach nur noch übel. Danke für dieses ausführliche Video, das werde ich beim nächsten Projekt zur Kalkulation verlinken!
@marketingstratege1849
@marketingstratege1849 Жыл бұрын
100 Prozent Zustimmung auch von mir. Häufigste Ursache bei mir ist oft, dass einfach das konkrete Zielbild überhaupt nicht klar und/ oder nicht konkret aufgeschrieben wurde. Es fehlt Entscheidern leider auch oft an absoluten Grundkenntnissen der Softwareentwicklung. Leider werden auch Softwareprodukte so vertrieben, dass alles immer ganz leicht verknüpft werden kann, was sich fast immer als falsch herausstellt und mit 1 Tag Aufwand hätte überprüft werden können, stattdessen werden 30 Tage nachträglich entwickelt...
@karlgustav9960
@karlgustav9960 Жыл бұрын
Guter Vortrag, stimmt aus meiner Persönlichen Erfahrung als (Frontend) Entwickler -> UX Designer -> PO auch genau so. Melvin Conway hat’s doch im Grunde schon vor Jahrzehnten geschrieben… Auch Onkel Bob (Robert Martin) hat dazu einen schönen Graphen gezeichnet. Das Problem an der Sache: die Vermutung, das gute Planung, gute Architektur und gute QA Mittelfristig (wir sprechen über wenige Wochen) den logarithmischen “Wir machen einfach” Prozess überholen, lässt sich leider nicht beweisen. Es gibt in der Softwareentwicklung keine AB Tests oder Doppelblindstudien, mit denen man beide Ansätze vergleichen könnte. So ist es in der Argumentation mit Stakeholdern immer schwierig, “ach das stimmt doch alles garnicht, du hast doch nur schiss, als Führungskraft muss man auch mutig sein…” 😮
@jodrei7643
@jodrei7643 Жыл бұрын
Wenn man was macht sollte man sich die zeitnehmen und es gleich richtig machen. Alles andere beißt einem dann wenn man es am wenigsten brauchen kann, da Zeitdruck etc..
@harald4game
@harald4game Жыл бұрын
Nicht zu unterschätzen ist die Infrastruktur, ich z.B. bin gerne mal Stunden oder Tage damit beschäftigt Probleme mit dem Proxy zu umschiffen. Ohne Proxy dauert ein Versuch 30sek mit 30min, da ist schon klar was kostet. Die Wartezeit. Oder man wartet ein paar Monate auf die Genehmigung einer Software, die dann abgelehnt wird. Und durch die schlechtestmögliche Alternative ersetzt wird, so dass die Entwicklung so richtig am Gemüt rumhobelt. Hauptsache es kostet nix und ist sicher.
@yt7042
@yt7042 Жыл бұрын
Ein großes Problem sind Qualitätsprobleme auf Entscheider-Ebene. :-) Schöne Woche!
@christianbaer2897
@christianbaer2897 Жыл бұрын
Man setzt sich als Entwickler alle 2 Wochen hin und guckt wie man die eigene Arbeit besser, effizienter und schneller machen kann. Man reduziert mit Hilfe dieser ganzen Optimierungen die mittlere Zeit pro Feature/Story/Ticket auf irgendwas um die 3 Tage von "Wir fangen an zu entwickeln" bis "Wir können das jetzt deployen" und dann kommt irgendwer und sagt "Die Softwareentwicklung dauert zu lange". Ja... Nur halt nicht das Programmieren. Was lange dauerte waren die "Fachabteilungen", die sich erst mal auskäsen mussten wie das ganze denn aussehen soll, was es machen soll und wie viel Geld Feature X denn bringen würde. Wie du ja schon gesagt hast, sind an der Software immer mehrere Leute bzw. "Gewerke" beteiligt. Die Softwareentwickler*innen können so schnell sein wie sie wollen, aber wenn es vorher 2 Monate dauert bis mal jemand sagt "schreibt dafür Code" und dann dauert es noch 2 Wochen bis es dann endlich in "Production" geht, dann wird Softwareentwicklung teuer, weil langsam.
@orange-vlcybpd2
@orange-vlcybpd2 Жыл бұрын
Jetzt brauchen wir ein Video, wo erklärt wird, dass Agile eben nicht heisst "Wir fangen irgendwie erstmal an, und schauen dann was es wird. Ist ja alles flexibel".
@W4ldgeist
@W4ldgeist Жыл бұрын
Ein wichtiger Punkt warum Software Entwicklung immer noch "so teuer ist": Die Ansprüche an alles was wir entwickeln, besonders im Web, sind explodiert. Vor 20 Jahren haben wir noch einfache, statische Webseiten gebastelt. Da hatten wir zwar kein Tools, aber die Ansprüche waren so gering, dass man sie auch nicht brauchte. Heute haben wir viele Tools, Frameworks etc. aber die Ansprüche sind schneller gewachsen als die Arbeitserleichterungen durch Werkzeuge. Deswegen ist Software Entwicklung eben trotz aller Anstrengungen immer noch "so teuer".
@kiwibu
@kiwibu Жыл бұрын
Kann ich bestätigen
@jkhofmann
@jkhofmann 11 ай бұрын
Danke. Das ist leider oft die Realität. ❤
@kiwibu
@kiwibu Жыл бұрын
Mich würde mal interessieren, ob es ein Positivbeispiel mit dieser hohen Anfangsinvestition gibt. Wer macht denn am Ende wirklich die Schlussrechnung, ob es denn im Gesamten wirklich so billiger geworden ist. Es finden ja nie Projekte vergleichend parallel statt. Wenn aber bereits die Zufriedenheit mit dem Projektergebnissen hoch ist, ist das schon mal ein gutes Zeichen. Ich hab leider die Erfahrung gemacht, dass gut laufende Projekte mit super guten Ergebnissen doch irgendwann vom Controlling als „müssen günstiger werden“ betrachtet werden und dann geht es nur noch abwärts.
@marcello4258
@marcello4258 Жыл бұрын
Für low/no Code brauchst du dennoch Software Entwickler. Ich komme mehr aus dem data Bereich, da haben Anbieter wie tableau auch versprochen alles einfacher zu machen, in der Praxis hat das aber nicht geklappt.
@Andreas-gh6is
@Andreas-gh6is Жыл бұрын
Outsourcing kann funktionieren.... man muss aber an die richtigen Entwickler geraten, die erstens überdurchschnittlich gut sein sollten und zweitens in der Lage sind, weitgehend barrierefrei zu kommunizieren. Kompromittiert man diese Voraussetzungen, braucht man mehr Interface-Leute, die sich auch erst mal rentieren müssen. Mir scheint, selbst die kleinsten Outsourcing Projekte kommen nicht aus ohne eine Vollzeitstelle beim Auftraggeber zu beschäftigen.
@yannick5099
@yannick5099 Жыл бұрын
Vielleicht liegt das nur an meiner Bubble, aber ich habe selten einen Berufszweig gesehen wo die Verantwortlichen so konsequent und selbstverständlich in den Prozess und die technischen Details eingreifen wie bei der Softwareentwicklung. Hier ist dein Hammer, bitte fälle damit Bäume. Dann ist da noch die Hype-Driven-Development, wo auf einmal für Big-Data, Blockchain, NFTs oder AI auf einmal massiv Geld da ist und ganze Teams aus dem Boden gestampft werden, für die aktuellen Kernthemen des Business aber stundenlang über jeden Cent verhandelt wird. Bei dem Thema Node.js vs Go würde ich widersprechen wollen. Wenn es egal ist, dann gewinnt für mich immer Go. Einfach weil es wesentlich performanter ist und weniger Ressourcen verbraucht. Die Komptibilitätsgarantie ist auch sehr nett für die Wartung. Das sind alles Kosten, für die wir als Entwickler verantwortlich sind und mit denen oft sehr verschwenderisch umgegangen wird. Software neu schreiben zu müssen, weil die Performance nicht mehr ausreicht, ist nicht allzu selten. Ich möchte mich da aber nicht zu sehr beschweren, immerhin schafft das für mich ordentlich Projekte =).
@HoD999x
@HoD999x Жыл бұрын
ich denke man kann gar nicht so gut planen wie es nötig wäre - mein ansatz ist daher, das system so simpel wie möglich zu halten. komplexität hat zinseszinseffejte
@alexandergessner9318
@alexandergessner9318 Жыл бұрын
voll auf den punkt gebracht, danke
@andreistein2429
@andreistein2429 11 ай бұрын
Sehr gut erklärt 👍👍👍
@falkheinrich7128
@falkheinrich7128 Жыл бұрын
Super danke. Kurz, präzise alles umrissen worauf es ankommt Allo Sätze die mit "Man sollte" beginnen zum Einrahmen sind zum Einrahmen. Es ist das Ringen zwischen Kurzfristigkeit und Langfristigkeit. Schnelle Erfolge zu geringen Kosten das Mantra jedes Betriebswirtschaftlers. Es wird oft nicht erkannt von diesen Controllern und Betriebswirtschaftlern, dass Qualität auch in einem Softwareprodukt liegt. Sie meinen, wenn es funktioniert, dann ist der Qualität genüge getan. Dass die Kosten erst mit der Wartung beginnen beim Einarbeiten von Änderungen, dass ist ihnen nicht klar. Ohne Tests zu arbeiten ist wie Reiten auf der Rasierklinge. Ich kann nur hoffen, dass ich so schnell keine Änderung einbauen muss, denn dann würde ich wieder Fehler einbauen unbeabsichtigt natürlich. Wenn das Programm schon älter ist kann ich mich nicht mehr erinnern an die Details, da helfen mir die Tests. Sehr guter Beitrag nicht nur für Developer sondern auch für Betriebswirtschaftler.
@jamespeterson7979
@jamespeterson7979 Жыл бұрын
Der Verzicht auf Qualitätssichernde Maßnahmen hat leider nicht zu dem gewünschten Ergebnis geführt das die Software schneller fertig wird. ^^ Das Projekt hat von Anfang an kein klares Ziel wo es hin gehen soll, pausenlos kommen Änderungen. Die Software Architektur wird immer komplizierter, Änderungen dauern immer länger und behobene Fehler tauchen wie von Geisterhand plötzlich wieder auf. Ohja genau so kenn ich das xD. Der zeitliche Rahmen muss ja immer von Anfang an feststehen, das Zeitkontingent ist abgenickt und als Entwickler sitzt du da und denkst: "Also der einzige Weg das in der Zeit zu schaffen, ist wenn ich einen Haufen Abkürzungen nehme und der Code damit noch komplizierter und undurchsichtiger wird" Ich habe mir auch ein Post-It an meinen Monitor geheftet, darauf steht: "Sei schneller!" und "Sei Besser!". Hat nicht funktioniert -_-
@llothar68
@llothar68 Жыл бұрын
Eine absolute Katastrophe ist dieser Turm von Babel Problem. Wir haben immer weniger grossartige Allzweck Librarires weil mittlerweile auch alles hier zerfaellt in immer kleinere Gruppen.
Жыл бұрын
Love Laravel xD
@pixelasm
@pixelasm 11 ай бұрын
7:50 EXAKT das Problem sehe ich auch immer wieder: Mangelnde Ziel definition und daraus resultierende Änderungsschleifen sind das Hauptproblem in der Entwicklung.
@dustsucker4704
@dustsucker4704 Жыл бұрын
Bei mir in der Firma wird vorher einmal alles fest gelegt wie es denn sein soll und dann wird entwickelt und in 99%der Fälle kommen noch sachen im Nachhinein dazu aber so das es vernünftig implementiert werden kann
@mugiwaranoadi5932
@mugiwaranoadi5932 Жыл бұрын
Warum Software auch nicht günstiger wird, liegt daran, dass der Standard gestiegen ist. Die Kunden halten viele Funktionen für selbstverständlich, weil sie in den ganzen großen Produkten implementiert sind. Ganz nach dem Motto: Wenn es „jeder“ hat, dann sollte es ja einfach und schnell gehen. Man denkt so ein mehrstufiges Abo-System mit eigener Userverwaltung und automatischer Abrechnung inkl. Monitoring und analytics ist doch selbstverständlich.
@frederick6720
@frederick6720 Жыл бұрын
Softwareentwicklung wird nur dann zu teuer wenn die Kosten unvorhersehbar steigen. Das passiert, wenn kein Software Architekt dabei ist, der durch seine Erfahrungen eine wartbare und erweiterbare Umgebung schafft. Oder wenn die einzelnen Entwickler zu unerfahren sind. Das ist tatsächlich ein großes Problem und gar nicht so unwahrscheinlich, da die Anzahl an Softwareentwicklern sich ungefähr alle 5 Jahre verdoppelt und daher auch 50% weniger als 5 Jahre Erfahrung haben. Ziele sind bei der Softwareentwicklung nur selten definiert und schon gar nicht zum Anfang des Projektes. Selbst die Kunden wissen oft gar nicht was sie haben wollen, bis sie etwas sehen was nicht ihren Vorstellungen entspricht. Deshalb muss man Agile Softwareentwicklung betreiben um dauerhaft Feedback zu erhalten.
@getherovideo
@getherovideo Жыл бұрын
Das Thema trifft genau auf das zu, was ich über die Jahren beobachte. Wenn gespart wird, egal aus welchem Grund, wird das Produkt mit der Zeit, mit großer Wahrscheinlichkeit mehr kosten. Ist Softentwicklung teuer? Bei der Aussage habe ich immer den Eindruck, dass man nicht bereit ist, das Geld für eine gute Lösung auszugeben. Am Ende kommt ein Ergebnis, dass vielleicht überwiegend Funktioniert, aber an Qualität mangelt.
@yannickLamp
@yannickLamp Жыл бұрын
Aktuelles Projekt, aktueller Kunde. Tickets sind teilweise fachlich noch nicht ausformuliert, sollten am besten schon im letzten Sprint umgesetzt sein. Abhängigkeiten zu andere Komponenten sind vorhanden, Ticket der anderen Komponente und Team wird aber nicht im Sprint davor eingeplant, sodass die API im aktuellen Sprint angebunden werden kann, sondern im gleichen. Teils wird das Ticket, des anderen Teams, erst wenige Tage vor Sprint Ende fertig und dann wird gewünscht, dass wir das Feature noch schnell umsetzen, damit es pünktlich fertig wird.
@yksnidog
@yksnidog 11 ай бұрын
Sichtflug wäre besser als das aktuelle Stochern im Nebel. ^^ Bei meinen Projekten gibt es aus unerklärlichen Gründen einen Plan. Ich rationalisiere eher die weg, die sowas sagen wie "Entwicklung kostet zu viel"... ;-)
@chrikrah
@chrikrah Жыл бұрын
Wie lässt sich den das agile Mindset mit dem kombinieren was du sagst bzgl. lieber Weitsicht als Kurzsicht? Lässt sich das miteinander vereinbaren?
@DJone4one
@DJone4one Жыл бұрын
Generell kann man aber sagen, das man schon jemand brauch, der auch Ahnung von Software-Code hat, damit man auch Fehler beheben kann. Denn solange eine KI wie ChatGPT aus Fehlern nicht lernt und immer wieder den selben Code dazu schreibt (der Fehlerhaft ist), so kann auch nichts besser werden. Die Baukasten sind ja auch nur so gut wie ihre Anwender. Ich glaube kaum das Elfriede 47, Verwaltungsangestellte und Katzenliebhaberin dann schon sich ein eigenes Tool zusammenbaut, wenn sogar die Schnittstellen in der Verwaltung nicht mal eingerichtet sind.
@FrediBlu
@FrediBlu Жыл бұрын
Super Beitrag!!!
@GregorSklorz
@GregorSklorz Жыл бұрын
Ja, das habe so auch schon viel zu oft erlebt. Interessant ist aber dass diese Fehler nach Jahren immer noch genau so passieren. Und dabei ist mir zumindest aufgefallen dass darin immer Manager das Sagen haben, welche noch nie ein anderes Software Projekt erfolgreich abgeschlossen haben. Sie kennen es also nicht anders und glauben wirklich: "Das ist halt teuer und schwer kontrollierbar" Der Zenit der Jammers kommt dann wenn man mal den Entwickler vertraut, aber dann die technische Leitung jemandem übergibt der lediglich am lautesten ist oder am längsten im Unternehmen. Natürlich ohne Erfahrung wie es denn besser gehen könnte. Vielleicht mal ein Tutorial gesehen oder auf einer Konferenz gehört. Aber ohne Erfahrung. Also neue Tech mit alten Paradigmen genutzt oder hart nach Schulbuch ohne wesentliche Abwägungen für die Realität. Und damit wird alles nur noch schlimmer.
@Andreas-gh6is
@Andreas-gh6is Жыл бұрын
Lowcode ist notwendig. Aber mit Lowcode spart man keine Entwicklungsarbeit, sondern es wird von Nichtentwicklern Entwicklungsarbeit geleistet, die sonst wahrscheinlich nicht geleistet werden würde. Es ist ja auch nicht so, dass die Lowcode-Benutzer deutlich geringer ausgebildet oder bezahlt werden, als echte Entwickler. Das sind auch Akademiker, nicht selten regelrechte Wissenschaftler.
@berndczech1554
@berndczech1554 Жыл бұрын
Aus meiner Erfahrung fehlt es in der Praxis an Leuten, die *Produktentwicklung* ernst nehmen. Häufig sind ProductOwner umgeschulte Projektmanager ohne Scope für Ihre eigentliche Aufgabe, das *Produktmanagement* . Ich merke oft, dass bei den ersten Rückfragen PMs nicht wissen wie sich Ihr Kunde Ihr Produkt vorstellt. Aber: Der Kunde weiß das ja auch nicht, also machen wir im Zweifel erstmal irgendwas, nach Gefühl.
@jwlzloff26
@jwlzloff26 Жыл бұрын
Schöner Vortrag :). Ich glaube allerdings um die entsprechenden Leute mitzunehmen, welche einen Teil der aufgezeigten Verantwortlichkeit tragen, bräuchte es noch ein paar zahlen und Beispielrechnungen. Nachhaltigkeit catched leider erst mit einer nachvollziehbaren Rechnung. Als Design Philosophie oder Lifestyle erreicht man meiner Erfahrung nach nur die Bubble die ohnehin affin für eine solche Denkrichtung ist. Ist ja auch bequemer und erstmal risikoärmer wenn man aufs vertraute setzt ^^.
@kiwibu
@kiwibu Жыл бұрын
Mich würde mal interessieren, ob es ein Positivbeispiel mit dieser hohen Anfangsinvestition gibt. Wer macht denn am Ende wirklich die Schlussrechnung, ob es denn im Gesamten wirklich so billiger geworden ist. Es finden ja nie Projekte vergleichend parallel statt. Wenn aber bereits die Zufriedenheit mit dem Projektergebnissen hoch ist, ist das schon mal ein gutes Zeichen. Ich hab leider die Erfahrung gemacht, dass gut laufende Projekte mit super guten Ergebnissen doch irgendwann vom Controlling als „müssen günstiger werden“ betrachtet werden und dann geht es nur noch abwärts.
@rainerdechet
@rainerdechet Жыл бұрын
Mega Video wieder ... ich dreh den Spieß mal um, bei wem ist es nicht so? 😅
@bsdooby
@bsdooby Жыл бұрын
7:00 Gibt's den Ausdruck "Silberkugel" auf Deutsch? ;)
@thenativeweb
@thenativeweb Жыл бұрын
[gr] Also ich bilde mir ein, dass ich das schon gehört habe. Die „magische Silberkugel“.
@Volker-Dirr
@Volker-Dirr Жыл бұрын
Ich kenne den Ausdruck nur in anderen Zusammenhängen. Da ist das dann aber Wort wörtlich und es geht es um Vampire. Vermutlich etwas passender ist der Ausdruck "eierlegende Wollmilchsau" oder "Wunderwaffe" oder "Königsweg".
@bsdooby
@bsdooby Жыл бұрын
Auf Englisch ist das ein häufig verwendeter Ausdruck: Allheilmittel.
@bsdooby
@bsdooby Жыл бұрын
BTW: mir hat das heutige Video sehr gut gefallen. @Golo: voll ins Schwarze getroffen mit der Analyse.
@alexandershendi7428
@alexandershendi7428 Жыл бұрын
Wie in "no silver bullet"?
@christianrupp8273
@christianrupp8273 Жыл бұрын
Denke es ist nur noch eine Frage der Zeit (wenige Jahre), bis der Großteil der Entwickler überflüssig wird. Ich könnte bereits heute auf einen Teil meines Teams verzichten und stattdessen KI verwenden.
@hra4242
@hra4242 Жыл бұрын
Huhu Golo, ich gucke deine Videos super gerne, auch wenn ich nicht professionell Software entwickele. Ich habe nur mal eine Frage, bzw. vlt ist das auch ein Video Thema für euch. Ich arbeite als System Administrator, also jemand der viel Systemverwaltung und maximal Skripting betreibt. Wie verhält sich das denn bei Skripting? Sollte man dafür auch Richtlinien und Prozesse definieren? Besonders wenn man moment der einzige ist der Skripte schreiben kann?
@thenativeweb
@thenativeweb Жыл бұрын
Hey 👋 Das ist eine gute Frage … Also grundsätzlich würde ich erst einmal sagen, dass es sich tendenziell immer lohnt, Richtlinien und Prozesse zu definieren, weil damit eine gewisse Einheitlichkeit etabliert wird, von der man auch selbst profitiert - und zwar auch dann, wenn man (wie Du) alleine arbeitet. Denn auch Dein zukünftiges Ich ist sicherlich dankbar, wenn bestimmte Dinge wie zB das Deployment nicht für jedes einzelne Skript individuell und anders sind, sondern wenn Du Dich darauf verlassen kannst, dass Xyz eben immer nach Schema F läuft. Allerdings ist die Frage natürlich, wie weit man das treiben kann und will. Denn in der Softwareentwicklung gibt es zumindest bei einigen Unternehmen das Verständnis, dass Qualität, Richtlinien, Prozesse & Co. wichtige Themen sind - inwiefern das auch bei der Administration so gesehen wird, da wage ich mal, ein Fragezeichen dranzumachen. Klar, wenn das sowieso alles nah am Code ist (Stichworte Infrastructure as Code, DevOps, …), dann vermutlich eher, aber ob jetzt zB Verständnis dafür da ist, warum Du ein Bash-Skript linten und testen willst, das ist halt die Frage … Trotzdem glaube ich, dass man am Ende davon profitiert, wenn man es macht. Und ich würde mir auch gar nicht zu viele Gedanken darüber machen, ob man das "darf", sondern es einfach machen, wenn es für Dich zu Deinem Selbstverständnis Deines Jobs dazugehört. Hilft Dir das?
@Ciddor89
@Ciddor89 11 ай бұрын
zu 10:10 - 11:30 falsche Diskussion: Die Wahl der Sprache kann schon sinnvoll sein - aber nicht auf Grund irgendwelcher sprachenspezifischen Eigenschaften, sondern schlicht und ergreifen vor dem Hintergrund: a) hab ich Fachpersonal, das damit umgehen kann und/ oder b) bekomme ich Fachpersonal, welches das Zeug später weiterbetreiben kann. Oft machen sich Unternehmen gerade an diesem Punkt abhängig von einem einzigen Unternehmen / Entwickler.
@helidrones
@helidrones Жыл бұрын
Leute in entsprechenden Positionen sind oft an kurzfristigen Erfolgen interessiert, weil sie die Erfolge für sich selbst einfahren möchten, nicht für etwaige Nachfolger.
@timb00
@timb00 Жыл бұрын
super video :)
@hansvetter8653
@hansvetter8653 3 ай бұрын
Natürlich ist die Software-Entwicklung viel zu teuer! Warum? ... nun ... weil die Geschäftsmodelle nicht skalieren! ... typisches Beispiel: verlängerte Werkbank (Consulting) ... Geld für Arbeit ... das skaliert nun mal naturgemäß nicht. Übrigens ist das allererste MVP naturgemäß immer eine Landing-Page, die Feedback über die Nachfrage nach Lösungen sammelt ...
@huskynarr
@huskynarr Жыл бұрын
Mein Favorit: Outsourcing mögliichst preiswert und nicht qualitativ recherchiert. Am Ende zahlt man doppelt und dreifach.
@X39
@X39 Жыл бұрын
IMO gibt es auch noch das Nutzer Problem, bei dem im Grunde alle gerne eine Excel Oberfläche hätten statt dem Programm, wie ist egal, Hauptsache excel. Nun könnte man einfach sagen, super Idee, wir packen es in den Backlog und ignoriert es, weil die Leute eben auf Dauer mit Ordentlichem UI Design besser klar kommen werden, aber dadurch, dass die Leute eben einfach drauf Pochen, dass es Excel sein muss (und meist auch die Sind, die den Entwicklern was sagen dürfen), sorgt es dann am Ende dafür, dass ein Hässliches und nicht wirklich flüssig verwendbares Excel raus kommt, statt einem neuem System.
@ernstgreiner5927
@ernstgreiner5927 Жыл бұрын
Gibt es Langzeituntersuchungen die das Thema Testen von Software genauer beleuchten?
@cyrusol
@cyrusol Жыл бұрын
Ich stimme dem überhaupt nicht zu, dass Programmierer und Entwickler etwas anderes wären. Ist natürlich Definitionssache. Wäre aber unglaublich schade, wenn einer Firma eine gute potenzielle Fachkraft verloren geht, weil die den Begriff Programmierer mehr mag als Entwickler.
@NeverCodeAlone
@NeverCodeAlone Жыл бұрын
Bei den tollen SaaS Angeboten von Shopify etc. musst du auch als Team erstmal zeigen, warum du billiger bist.
@dominik4496
@dominik4496 Жыл бұрын
Shopify selbst musste ja auch entwickelt werden (Softwareprojekt) und kennt Grenzen, wenn es um die Individualisierung und auch Lastspitzen geht.
@W4ldgeist
@W4ldgeist Жыл бұрын
Alles Gesagte kann man komplett unterschreiben. Leider ist es all zu häufig "Entwicklerlogik". D.h. diese Argumentation können nur Entwickler nachvollziehen. Die ganzen Manager-Types hören diese Argumente und sagen dann in bester Dunning-Kruger-Manier: "Was stellt ihr euch so an? So schwer kann das doch nicht sein! Das muss doch gehen!" Und damit sind dann alle Diskussionen und Verbesserungsvorschläge, Änderungswünsche etc. beiseite gefegt.
@ratoshi21
@ratoshi21 Жыл бұрын
Jahr 1 eines Softwareprojekts: wir ÜBERSCHÄTZEN die relevanz von Qualitätssicherung und UNTERSCHÄTZEN Kundenfeedback Jahr 5+: wir UNTERSCHÄTZEN die relevanz von Qualitätssicherung und ÜBERSCHÄTZEN Kundenfeedback
@nietur
@nietur Жыл бұрын
Offshore 15€ die Stunde für Senior Dev, was will man mehr
@dominik4496
@dominik4496 Жыл бұрын
Die haben doch inzwischen auch längst gelernt was sie wert sind oder reden wir hier von simplen Todos?
@nietur
@nietur Жыл бұрын
@@dominik4496 Nein, haben sie nicht.
@AndreasJung
@AndreasJung Жыл бұрын
AMEN
@Andreas-gh6is
@Andreas-gh6is Жыл бұрын
Excel = LowCode...
@life_xplorers
@life_xplorers Жыл бұрын
Wer nicht weiß wohin, dem hilft auch Galoppieren nichts.
@beerensaft413
@beerensaft413 Жыл бұрын
Software = Bananaware Wird halt reif beim Kunden!
@turefriese8937
@turefriese8937 Жыл бұрын
Die Argumentation ist gut. Ist schon viel Wahres drann. Allerdings gibt es einen Free Lunch der erwähnenswert ist: Ausgereifte open source frameworks, die die Softwareentwicklung besser und billiger machen können. Man muss auch sagen dass das Oualitewtsstreben auch übertrieben werden kann, was zu unnötigen Tests, zu hochgeschraubten code-standards und zum "Goldplating" führt. Ein zu hoch gesetzer Qualitätsstandard ist ausserdem schwierig wieder loszuwerden...
@ProfWho-ut5he
@ProfWho-ut5he Жыл бұрын
Teuer bleibt es dennoch. Sehr teuer. Sehr sehr teuer. Als Startup stehe ich vor dem praktischen Problem dass ich es einfach nicht bezahlen kann. Ein guter Entwickler verdient viel mehr als der CEO; ich weiß da nicht weiter. Einfach nach Indien gehen funktioniert auch nicht und low Code, no Code funktioniert nicht mit einem neuartigen Produkt.
@user-sd5rw9em2l
@user-sd5rw9em2l Жыл бұрын
Meine Antwort richtet sich an diejenigen, die den Beitrag lesen, nicht an den Verfasser: Eine Idee für ein Produkt zu haben ist nur 1% der Arbeit. Bei der Umsetzung der Idee muss der Ideengeber der technische Experte für die Umsetzung sein. D. h. bei einer Idee (Startup) zu einen Softwareprodukt ist der CEO ein überdurchschnittlicher Softwareentwickler. Er kann einen Großteil der anfallenden Entwicklungsarbeit selbst erledigen und macht das auch. Damit liegt die Wertschöpfung bei Ihm und er kann sich ein CEO Gehalt zahlen. Das Gehalt spiegelt die Qualifikation für die Aufgabe wieder. Wenn der CEO nur die Arbeitsanweisung "setzt meine Idee in ein Produkt um" beisteuert, dann ist sein Beitrag zur Wertschöpfung entsprechend gering. Kann man so machen wenn man a) Elon Musk ist und b) genug Geld in die Idee buttern kann, weil Investoren einem das Geld nachschmeißen. Für alle kleinen Startups heißt es: selber können, darum selber machen.
@ProfWho-ut5he
@ProfWho-ut5he Жыл бұрын
@@user-sd5rw9em2l Das ist eine sehr sehr unübliche Situation. Die allermeisten Startups produzieren Lösungen für ein spezifisches Vertical, zb Gesundheit, Pharma, Dating, Fitness usw und die Gründer kommen aus diesen Bereichen weil sie die Idee, die Netzwerke und Expertise mitbringen. In praktisch allen diesen Situationen ist der CEO kein Entwickler. Ich kenne hunderte Software Startups und keines davon wurde von einem Entwickler gegründet. Das Umsetzten der Idee kann dann jeder einigermaßen gute Entwickler machen, dh die Expertise für die Umsetzung ist wenig speziell, es gibt Millionen von Entwicklern. Der Inhalt und die Idee des Produktes sind viel viel wichtiger als die eigentliche Umsetzung. Das Gehalt spiegelt in fast allen Fällen nicht die Expertise wieder. Darum ist es für ein Startup so schwer. Ich baue gerade 3 Startups auf und weiß noch nicht wie ich das Problem lösen kann, denn ich bin kein Entwickler.
@gerhardq1
@gerhardq1 Жыл бұрын
Tom DeMarco stellt die Frage anders: "Warum ist die Softwareentwicklung eigentlich so billig?"
@salahaddinayyubialkurdi1145
@salahaddinayyubialkurdi1145 11 ай бұрын
Die zu hohen Lohnkosten? In Deutschland? 😂😂😂 Wohl eher unterbezahlt!
@Roxas257
@Roxas257 11 ай бұрын
"Das bisschen Testen", das können auch nur nicht Entwickler sagen 😂😂😂
@LA-fb9bf
@LA-fb9bf Жыл бұрын
Warum so teuer? Meine Erfahrung: die Programmierer programmieren kaum noch, sondern konfigurieren nur noch teuer eingekaufte Software. Oft mit dem fadenscheinigen Argument, es sei dann ausgereifter und sicherer. Blödsinn! Selbst entwickelte, maßgeschneiderte Software ist ebenfalls gut! Ein guter Entwickler hat das drauf bzw. lernt das. Es ist schließlich sein Beruf!
@Andreas-gh6is
@Andreas-gh6is Жыл бұрын
Ich glaube es werden sich nur Entwickler dieses Video anschauen, die werden allem zustimmen aber keine wirklich neue Erkenntnis gewinnen.
@huginn1879
@huginn1879 Жыл бұрын
Entwickler und Entwicklerinnen, wieso nicht einfach das generische Maskulin benutzen? Entwickler sind meiner Erfahrung eher nicht so auf dem gender Trip :) Vor allem du ziehst es ja auch gar nicht voll durch. Kommt einfach cringe und aufgesetzt über. Ansonsten echt gutes Video.
@Hofer2304
@Hofer2304 Жыл бұрын
Braucht man nur Enwickler? Sicher, sie sind nötig, aber so wie Bauarbeiter ein Haus nicht planen können müssen, müssen Coder nicht entwickeln können. Sie sollten dreckigen und unsicheren Code in sauberen und sicheren Code verwandeln können.
@IchBinKeinRoboter
@IchBinKeinRoboter Жыл бұрын
Der Mann hat recht, seit dem wir einen Projektmanager eingestellt haben ist die Entwicklung für uns intern und für den Kunden günstiger geworden.
Die beste Architektur für Deine Software // deutsch
23:10
the native web GmbH
Рет қаралды 8 М.
Warum TDD (Test-Driven Development) überbewertet ist // deutsch
20:13
the native web GmbH
Рет қаралды 10 М.
Bend The Impossible Bar Win $1,000
00:57
Stokes Twins
Рет қаралды 40 МЛН
Now it’s my turn ! 😂🥹 @danilisboom  #tiktok #elsarca
00:20
Elsa Arca
Рет қаралды 12 МЛН
Dad Makes Daughter Clean Up Spilled Chips #shorts
00:16
Fabiosa Stories
Рет қаралды 7 МЛН
Junior vs Senior: Die traurige Wahrheit // deutsch
16:40
the native web GmbH
Рет қаралды 10 М.
WARUM Softwareentwickler den Spaß verlieren...
11:51
David Tielke
Рет қаралды 16 М.
Windows 7 war GEIL, aber warum?
20:30
VersiXP
Рет қаралды 4,9 М.
So verarschen Dich Unternehmen bei der Bewerbung // deutsch
10:47
the native web GmbH
Рет қаралды 34 М.
So viel kosten Coding-Bootcamps wirklich
15:49
Programmieren lernen
Рет қаралды 9 М.
Top Entwickler:in? Diese 8 Fähigkeiten brauchst Du! // deutsch
21:59
the native web GmbH
Рет қаралды 7 М.
Meine ständige ANGST in der Softwareentwicklung
12:06
David Tielke
Рет қаралды 8 М.
"I Hate Agile!" | Allen Holub On Why He Thinks Agile And Scrum Are Broken
8:33
Das einzig wahre Betriebssystem zum Coden?! // deutsch
23:27
the native web GmbH
Рет қаралды 8 М.
Bend The Impossible Bar Win $1,000
00:57
Stokes Twins
Рет қаралды 40 МЛН