Weil es ist ja nicht so. Du kommst in den ersten Tag irgendwo in nen Team. Was macht dir XY alles klar? Bin dabei, gib her wo IDI, ja ich hab meinen Rechner schon mit, der ist schon, dass da schon alles eingerichtet, wir können loslegen Coding Body Deinem Podcast rund um Softwareentwicklung und aktueller Technews. Herzlich Willkommen. Was? Einen wunderschönen guten Tag und herzlich Willkommen zur neuen Folge vom Coding Buddies Podcast.
Es geht wieder los, wir sind wieder bereit, wir sind wieder da. Oh ja, Tino und ich, Tino, grüß dich. Grüß dich, fabi. Was geht ab? Alles gut bei dir? Ja, ich würde sagen, es geht mal wieder los. Es ist wieder Zeit. Oh ja, oh ja, wir sind jetzt auch glaube ich, langsam schon ganz cool gestartet ins Jahr oder so, wir sind wieder richtig drin. Ja, das Jahr läuft schon wieder. Also eigentlich ist ja 2024 jeder hat das schon jetzt schreiend geschrieben.
Ja, also weißt du dieses typische Nein, aber dieses typische, so das erste Datum was du im Jahr schreibst ist das Jahr vom letzten Jahr. Weißt du also sozusagen sowas wie 7.1. 23 nein, Scheiße. Ich finde das auch eine super gewöhnungssache, dann erstmal sich wieder ins neue Jahr zu gewöhnen beim Schreiben, da hast du recht, das geht mir wirklich immer so, ist total abgefahren, aber wahrscheinlich nicht nur mir so. Kleiner Tipp von mehreren Leuten
muss. Dir im Dezember schon ganz oft das Jahr, also die Zahl vom nächsten Jahr sagen. Du musst es schon verinnerlichen und dann läuft wie. Soll das aussehen, dass man dann irgendwie durch die Straßen geht und mit jedem, dem man spricht, sagt? Ach übrigens, das ist bei 2024. Nein, du stellst dich in den Garten und schreist ganz laut 2020 100 mal. Ich hab keinen Garten. Na ja, gut, OK, dann mach ich halt Schreibfehler auch kein Thema. Schreis aufs Fenster? Nein, keine Ahnung.
Merk es dir. Ja, merk dir einfach so. Wir haben 2024 los geht es, erzähl mal, was ist denn das Thema? Du hast doch was mitgebracht. Ja, wir wollen mal wieder eine Folge machen, und zwar eine Mythos oder Faktfolge. Oh yeah, das war cool letztes. Mal. Ja, und da hab ich jetzt mal eine Aussage mitgebracht. Aussage soll einfach heißen, wenn du mehr Leute in ein Projekt steckst, dann ist die Entwicklung der Software, die du sozusagen entwickelst,
schneller. Mehr Leute, schnellere Entwicklung quasi. Also. Mehr Softwareentwickler beziehungsweise mehr Softwareentwicklerin heißt auch gleichzeitig, ist quasi äquivalent zu einer schnelleren Entwicklung dieser Software. Ne, das ist quasi sozusagen das Thema, über das wir uns einmal ganz kurz ein bisschen unterhalten wollen in einer Mythos oder Fun Folge und dann halt mal gucken, ist das jetzt ein Mythos oder ist das ein harter Fakt? Was sagst du dazu? Was?
Wie könnten. Wir an die Sache rangehen. Naja gut, also im Prinzip kann man ja nur von eigenen Erfahrungen berichten, das würde ich jetzt auch mal machen. Also ich hoffe, wir machen das nicht nur ich.
Weil. Ja, ich glaub das kannst du ja jetzt nicht irgendwie mathematisch belegen oder so und sagen ja, das ist ein Fakt oder keine Ahnung, das ist Mythos, weil ne. Also würde ich sagen, lass uns doch einfach mal schauen, schauen wir noch mal die letzten Jahre zurück, so Projekte die wir gemacht haben und wie das da lief. Also also meine Erfahrung dazu ist, dass. Meistens.
Jetzt muss man aufpassen. Also ich will das ja auch nicht verallgemeinern, aber meine Erfahrung nach immer ist es eher so, immer ist immer so. Dass ab einer gewissen Anzahl an Entwicklern es nicht mehr schneller wurde, im Gegenteil. Da sind dann andere Probleme mit ins Boot gekommen, die teilweise oder auch oft dazu geführt haben, dass genau das Gegenteil passiert, also man nicht schneller wird, sondern eher langsamer. So, das klingt ja jetzt erstmal
ein bisschen. Ihr seid doch mehr Leute, mehr Leute, die Code schreiben und dann dementsprechend kann ja mehr Code schneller entwickelt werden und man müsste ja auch schneller vorwärts kommen, aber das. Tatsächlich ist das nicht die Erfahrung, die ich gemacht hab. Ich weiß nicht, wir können ja gleich auch noch mal so n bisschen begründen warum, aber ich würd gern mal wissen, wie
deine Sicht ist. Vielleicht haben wir ja jetzt quasi 2 Seiten und könnten gegenargumentieren oder argumentieren, warum wir der gleichen Meinung sind, also hau mal raus, wie siehst du das oder wie ist deine Erfahrung dabei? Ja, also ich hab auf jeden Fall auch schon in meiner Karriere, sage ich jetzt mal, Projekte ganz alleine gemacht. Das waren dann eher kleinere Projekte und sehr. Begrenzte Themen, die man eben halt auch alleine bearbeiten
konnte. Und ich habe auch schon in Teams gearbeitet mit 4 Leuten bis ungefähr so bis 8 Leuten. Also wenn es jetzt wirklich mit Leuten, meine ich wirklich Softwareentwickler bzw softwareentwicklerin. Und aber aber. Im gleichen an der gleichen Software also. 8 Leute, die wirklich, sage ich mal daran. Entwickeln genau. Also ich kenne ja. Schon ordentlich. Ist schon, ist schon ein bisschen. Nicht mehr so klein nennen.
Nee, auf jeden Fall nicht. Geh ich mit, aber das sind ja auf jeden Fall, es ist halt ne Bandbreite zwischen alleine und auch Stufen dazwischen, zwischen alleine und 8 ne so Leute. Und ich habe auf jeden Fall gemerkt, dass zumindest in dieser Range. Wie sagt man? Die Goldene Mitte sagt man, also die goldene Mitte in der Mitte lag also goldene. Mitte lag in der Mitte. Es man glaubt ja mal nicht, dass die Goldene Mitte auch wirklich
in der Mitte ist. Nee, aber so ich, ich fand auf jeden Fall, wenn man alleine arbeitet, ist es so der Punkt, dass ich finde, dass es relativ schnell geht, dass man quasi. Wenn man jetzt Leute hinzufügt, sagen wir mal, anstatt einen alleine zu arbeiten, auch noch eine zweite Person dazu packt, geht die Entwicklung auf jeden Fall schneller. Also soweit würde ich eigentlich fast immer gehen und sagen, das ist Fakt. In einem Gewissen, in einer gewissen Range funktioniert das fantastisch.
Ich würde auch sagen, dass zum Beispiel so bis 4 Personen kannst du ne relativ würde ich jetzt aus meiner Erfahrung sagen, ne relativ gute Aussage oder wäre die Aussage für mich würde ich zustimmen würde ich sagen ist OK. 4 Personen wird auch schneller. Ich würde aber zum Beispiel nicht sagen, dass wenn du sagst, du hast eine Person und das ist jetzt quasi eine. Weiß nicht. Eine Entwicklung von 1, dass quasi bei 4 Personen die Entwicklung auch auf ich sag jetzt mal die fiktive Zahl von 4
im Fortschritt steigt? Also ich würde nicht sagen, dass
es linear ist. Ja genau, und da könnt ich würd ich dich jetzt zum Beispiel mal fragen, bevor ich das jetzt noch abschließe, bloß bei 8 Leuten hab ich schon gemerkt, da wurde es auf jeden Fall schon mal wieder n bisschen träger, also die Kurve flacht ab würd ich sagen und dann ist halt die Frage geht sie irgendwann auch wieder runter das heißt also hat man zum Beispiel irgendwie vielleicht auch diesen Punkt, dass man sagt mit 16 Leuten ist man deutlich langsamer als mit 8
zum Beispiel, aber was meinst du denn was ich mit also wie stehst du dazu, wie kannst du dir das vorstellen wenn ich sage? 4 Leute sind nicht doppelt so schnell in der Entwicklung wie 2. Ja. Also noch mal, falls das nicht ganz rüberkam, ne, wenn wir jetzt Projekt und Entwicklung sagen, dann reden wir ja wirklich von einem Thema. Also natürlich ab ner gewissen Größe sage ich mal. Wenn man jetzt wirklich n sehr
großes Projekt hat. Sind es natürlich mehr als 48 Entwickler, Entwickler, dann ist es halt zweistellig, vielleicht sogar dreistellig, je nachdem wie riesig das Projekt ist. Wir reden ja jetzt wirklich davon, an einem Thema zu arbeiten, ne, also jetzt nicht, nicht ein Feature zum Beispiel, aber zum Beispiel ein Teilprodukt des gesamten. Oder Halt eines Standalone Anwendung.
Genau, weil da einfacher bin ich auf jeden Fall dann ganz bei dir, dass man sagt okay zu zweit auf jeden Fall zu viert, ist auch noch cool, dann kann man das noch sehr gut organisieren. Wie geht es weiter? Am besten hat man denn schon
einen, der so ein bisschen. Bisschen zumindest in die Rolle übernimmt, das zu koordinieren so ein bisschen vielleicht mit anderen Teams redet, also dieses, Wir hatten ja auch mal über Scrum geredet, so ein bisschen so den Product owner macht, sage ich mal und sagt Okay Leute, ich übernehme das, ich entwickle zwar noch mit, aber ich gucke schon mal, dass wir die richtigen Features machen, wann müssen wir das machen, also da muss halt Koordination rein, weil wenn
jetzt 4 Leute los sagen. Soll ich dir mal das in dem Moment mal? Das hab ich doch schon gemacht letzte Woche. Ja. Oder also mal übertrieben gesagt ne oder 2 nehmen sich morgens n Thema und nehmen sich das gleiche und reden nicht miteinander. Also. Das Entschuldigung, das Problem oder die die Challenge dabei ist ja, wenn du alleine bist, kannst du machen was du willst. Du bist dein eigener Herr, zu zweit musst du nur mit einer Person reden, vielleicht arbeitet man sogar im Pair, sage
ich mal und arbeite. Wie immer zusammen easy 34, das geht irgendwann nicht mehr oder macht keinen Sinn, dass alle denn auf den gleichen Bildschirm gucken. Dann kommt ja quasi nen nen Overhead rein an Organisationsaufwand. Ja. Und der ist ja noch bei 4 Leuten überschaubar. Ach, geht auch noch, aber irgendwann kommst du ja an den Punkt und da sehe ich halt immer oder da bin ich, werde ich dann quasi skeptisch, ob das wirklich noch schneller macht, dass das ja alles organisiert werden muss.
Ja. Also. Leute ja auch quasi integriert werden müssen. Ne, also das ist halt auch wirklich n seh ich auch so. Es ist n. Das ist auf jeden Fall einer der Painpoints, die ich auch identifizieren würde, wenn es darum geht zu sagen, man packt jetzt einfach nur mehr Leute drauf. Also das das Witzige ist ja, dass das ich das auf jeden Fall auch schon so, ich sag jetzt mal
aus. Manager Sicht gehört habe oder zumindest mitgekriegt habe, dass es wohl Leute gibt im Managementbereich, die vielleicht.
Diese Auffassung vertreten, dass man sagt, OK, wir haben jetzt eine eine Anwendung, die entwickelt werden muss, und wir haben jetzt zum Beispiel 4 Leute und diese 4 Leute sagen ja, wir werden wahrscheinlich in einem Jahr damit fertig und von Managementseite heißt es, naja, aber wäre jetzt schon wichtig, dass wir in einem halben Jahr fertig werden, also was können wir tun, und dann werden halt verschiedene Möglichkeiten gesehen, die meiner Meinung nach dann nicht immer ganz mit dem
Resultat deckungsgleich sind, weil wenn man dann nämlich zum Beispiel sagt, Ja gut. Man braucht ein Jahr mit 4 Leuten, also brauche ich ein halbes Jahr mit 8 Leuten. Die Rechnung ist total einfach. Würde ich mich halt hinstellen und sagen, das funktioniert so nicht. Also da würde ich definitiv mich hinstellen und sagen, das kann so genau nach dieser Rechnung eben nicht funktionieren. Und da kommt halt kommen halt so Punkte wie du meintest ne sowas wie n Overhead. Du hast Absprachen
untereinander. Du musst das ganze koordinieren. Du musst vielleicht sogar angenommen, du ramst von 4 Leuten auf 8 Leute hoch, dann hast du ja quasi noch ein Onboarding. Du hast ein Einarbeitungsprozess, das heißt, du hast auf jeden Fall irgendwie Overhead, der quasi irgendwie stattfindet und das. Da würde. Ich halt sagen, dass Slow teilt das Ganze zumindest entweder kurzzeitig runter, aber im Endeffekt auch durch diesen ganzen Overhead, der entsteht
eben halt auch langfristig. So heißt nicht, dass es sich runterslobt, dass man jetzt auf einmal langsamer wird, aber man wird auf jeden Fall nicht doppelt so schnell, weil man doppelt so viele Entwickler oder Entwicklerinnen quasi an ein Projekt setzt. Ja, ich glaube, das ist auch. Also ich war nie in der Position, sowas berechnen,
bestimmen zu müssen. Also ich will mich da auch nicht zu weit aus dem Fenster lehnen, aber ich habe halt öfter schon in der Vergangenheit das Gefühl gehabt, dass es so ist. OK, du hast ne gewisse Manpower, ein Entwickler kostet dich im Jahr so und so viel, der sagt Ich brauch n Jahr jetzt um dein Beispiel noch mal aufzugreifen, dann sind das Kosten von ja keine Ahnung x und wenn ich jetzt aber sage ich möcht es aber halb so schnell haben, muss ich einfach die Kosten sozusagen
verdoppeln. Ich stell noch einen Entwickler ein und dann kriege ich die Zeit gedrückt damit. Also dein Beispiel fand ich ganz cool weil man hat oft das Gefühl, dass irgendwie sowas im Hintergrund gerechnet wird, was aber irgendwie in der Praxis nie aufgeht. Ja, das mag zwar in der Theorie oder vielleicht auch vor der Mathematik. Keine Ahnung, irgendwie. Sinn machen, was da berechnet wird, aber in der Praxis habe ich persönlich noch nicht erlebt, dass das 1 zu 1 so
aufgeht. Also weil zum Beispiel ein Punkt, ich wollte dich nicht unterbrechen, aber ein Punkt, den ich auch super wichtig finde, ist, es ist ja nicht nur organisatorische Aufwand, der steigt. Ich finde, es ist auch ein zunehmender Aufwand, diesen ein Wissenstransfer herzustellen, definitiv also sowas wie.
Jeder weiß Bescheid, was passiert überhaupt in der Software, weil Worst Case bilden sich kleine Inseln auf einmal selbst innerhalb des Teams, weil ja die beiden machen immer das, die beiden machen immer das, weil das war jetzt so die Woche und da das läuft also weißt du die haben jetzt ihr wissen da wenn wir jetzt noch mal tauschen würden, dann wären wir ja wieder langsam. Das können wir jetzt auf keinen Fall machen, also schön so wie es ist.
Das läuft gerade so und dann wenn die jetzt mal ganz blöd davon ausgehst Fluktuation einer verlässt das Unternehmen oder wird krank was man ja nie hofft aber kann ja passieren und dann hast du halt so deine kleinen Heros auf deinen Inseln die wegfallen und dann geht da gar nichts mehr weiter und dann guckst dann guckt man halt richtig blöd auf gut Deutsch. Du musst ja gar nicht so weit gehen, dass es um Krankheit geht oder zum Beispiel um keine Ahnung, Abgänge.
Es reicht ja schon, wenn eventuell zu einem ungünstigen Zeitpunkt bestimmte Personen gleichzeitig im Urlaub sind. Ja, genau, das ist. Ein guter Punkt. Klar, man kann versuchen, sich da mal abzustimmen, aber das klappt ja auch nicht immer, ja, aber. Das ist ja zum Beispiel auch n Punkt.
Wenn wir jetzt gerade also so n bisschen abdriften, aber prinzipiell ist es ja nicht schlecht, wenn man genau auf sowas achtet, also sowas zu vermeiden, dass man eben schafft nen guten Wissenstransfer. Zu generieren, dass man quasi, dass jeder zumindest einen guten Überblick hat und überall mitarbeiten kann, was natürlich jetzt wieder für kleinere Teams spricht oder zumindest nicht dafür spricht, dass man sagen könnte, mehr Leute, schnellere Entwicklung oder doppelt so
viele Leute, doppelt so viel, doppelt so schnell Entwicklung. Aber wenn man dann darauf achten kann, durch diesen guten Wissenstransfer, den man hinkriegt, dann kann man ja sich auch selber eigentlich ein sehr viel schöneres Arbeitsklima schaffen. Wenn man dann zum Beispiel sagt, Ich möchte dann in den Urlaub und dann heißt es vielleicht sorry, aber das geht jetzt leider nicht.
Also da muss man auch immer überlegen, was springt für mich dabei raus und gerade so was, wenn man das im Hinterkopf behält und sagt Okay lass uns doch effizient vielleicht in den kleineren Teams arbeiten, wo jeder sozusagen. Auch n Guten ne wissensdurchmischung gut stattfinden kann, dann schaffst du dir vielleicht doch einfach ne schönere Perspektive für deine eigene Arbeit. Ja, auf jeden Fall. Das ist eigentlich ein ganz guter Punkt. Ich hätte aber noch einen
anderen. Also ich würde gerne noch ein anderes Date, das geht jetzt in die andere Richtung, aber was mir gerade noch dazu eingefallen ist. Es ist ja nicht nur so, dass ein. Ist wieviel quasi Organisation, also organisatorisches dazukommt oder wieviel man denn noch wegarbeiten kann, sage ich mal. Ich finde ein Punkt, der bei diesem ganzen Thema auch ne
riesen Rolle spielt. Ist ja, wie weit ist man fortgeschritten im Projekt, um noch mal dein Beispiel aufzugreifen, sagt man, wir brauchen ein Jahr, wenn man das Projekt startet oder braucht man noch circa ein Jahr und steckt schon ein 2 Jahre in der Entwicklung, also das heißt es geht so irgendwann auf die Zielgeraden und man merkt wir müssten jetzt doch ein halbes Jahr vorher releasen, also jetzt doch noch mal schnell Leute einstellen, damit wir das
einhalten können, das finde ich sind auch 2 ganz ganz unterschiedliche Sachen. Beispielsweise wenn ich gerade dabei bin, ein Projekt zu starten und Abschätze wie viele Entwickler brauche ich dafür und stellt dann zum Beispiel 4 Leute ab aus der Firma, die daran arbeiten sollen, dann können die sich ja von Grund auf quasi organisieren, dementsprechend das Projekt aufbauen und ja quasi dann daran arbeiten.
Ganz anders sieht es ja aus, wenn du beispielsweise ja mit 2 Leuten schon 2 Jahre an etwas arbeitest. Zu zweit schafft man in 2 Jahren jetzt auch schon einiges. Das heißt, das ist auch nicht mehr so wenig, was da entstanden ist. Definitiv. Und dann heißt es so, Ah Jungs, wir haben nur noch n halbes Jahr hier sind noch mal 2 Entwickler, jetzt seid ihr 4. Jetzt macht es bitte in der Zeit fertig. Weil ich mein, weißt du, worauf ich hinaus will?
Also ja, definitiv ja auch Gefahren mit sich, wenn ich da. Kurz einhaken kann, das ist ja auch genau der Punkt, den du auch schon so n bisschen angesprochen hattest oder angeschnitten hattest. Es geht ja um was man immer hat. Also es gibt 2 verschiedene. Also das hab ich auch selber
schon erlebt. Ne du fängst zum Beispiel bei einem Projekt an, hab ich gemacht so richtig grüne Wiese und man kann von vornherein richtig sagen OK es geht los, lass uns mal hier richtig geil von vorne starten, wir haben alles in der Hand. Das macht total Bock.
Kann ich auch jedem empfehlen, dass man das irgendwie auch mal machen kann und das ist cool, das war quasi n Team von 6 Leuten, alle hatten Bock und ja war auf jeden Fall n fähiges Team und das hat auf jeden Fall richtig gefloht das war geil. Nichtsdestotrotz hast du am Anfang.
Diesen diesen Effekt, dass du sagst okay man muss erstmal so eine gewisse Art von Teambuilding machen und zwar guckst du erstmal okay wie sprich also was für Konventionen, Absprachen trifft man am Anfang quasi explizit und was passiert so implizit zum Beispiel du merkst irgendwann ja okay der eine fängt dann und dann an, der andere fängt dann und dann an, du kannst das irgendwann, also es gibt manche Sachen, die du von vornherein richtig per Absprache regelst
und manche Sachen finden halt so unter der Hand irgendwann statt. Und dann gibt es ja noch den anderen Punkt, und zwar sowas wie zum Beispiel jetzt kommt jemand Neues in ein bestehendes Team hinein, dann hast du ja dieses ganze Teambuilding, hast du ja fertig, das heißt, du musst eigentlich diese eine
Person und. Beziehungsweise je nachdem, wie viele denn dazu kommen, musst du ja sozusagen Druck beschallen und dann kommt ja dazu ne wie du meintest, wenn du dieses, dieses dieses ganze Teambuilding schon hast. Die Leute können gut arbeiten, das läuft, das funktioniert, das float. Aber wenn du jetzt zum Beispiel sagst Verdoppelst das Team, dann hast du ja erstmal, je nachdem wieviel du auch schon geschafft hast.
Das ist ja auch was du gerade meinst, musst du ja den ganzen Leuten erstmal überhaupt, also nicht nur das fachliche, sondern auch noch also fachliche übermitteln. Was passiert hier, wie läuft das gerade, sondern zusätzlich auch noch, wie arbeiten wir hier eigentlich im Team? Und dann kann es ja wieder zu Konflikten kommen, weil vielleicht zum Beispiel jemand ganz, ganz anders arbeitet, als man das vielleicht irgendwie so im Flow schon geschafft hat.
Und da kann es dann halt auch noch mal zu Konflikten beziehungsweise auch Verzögerungen kommen. Das war mir jetzt noch mal so wichtig, dass auch noch mal so mit in den Raum zu werfen, weil das habe ich beides schon erlebt, zum einen neu anzufangen, ein Projekt sowie jemand kommt dazu, aber auch ich gehe in ein neues Team rein. Ja, so ne. Also. Das ist auf jeden Fall, ja, das ist das, finde ich.
Also die Erfahrung habe ich auch gemacht, das ist ja im Prinzip, wenn du sehr fortgeschritten bist in deinem Projekt und dann, dann kommen neue Leute dazu. Musst du ja Entwickler abstellen um quasi die neuen Entwickler zu onboarden. Das heißt zu erklären, wie sieht denn die Infrastruktur aus, was macht das Produkt überhaupt, weil es ist ja nicht so, du kommst in der ersten Tag irgendwo in ein Team.
Was macht dir xy alles klar, bin dabei, gib her wo ide ich habe meinen Rechner schon mit, der ist da schon alles eingerichtet, wir können loslegen. So läuft es ja nicht. Getrunken. Keine Witze, wenn jemand trinkt. Aber es ist ja doch eher so, dass man erstmal quasi so ein Onboarding macht. Was machen wir hier, was ist das Ziel, was ist der Projektplan zum Beispiel, also je nachdem,
wie agil das Ganze läuft und. Dauert das doch, bis so ein neuer Entwickler seine Manpower wirklich einbringen kann. Zusätzlich wird die Manpower eines bestehenden Entwicklers reduziert, weil er sich ja um den Neuen kümmern muss, was ja auch richtig ist. Keine Frage, ist ja nicht. Damit nicht sagen, Lass den im Regen stehen, der wird schon
irgendwann klarkommen. Das ist natürlich auch Quatsch, aber du musst ja trotzdem mal ehrlich sein und sagen, der Entwickler kann erstmal nicht in voller Leistung weiterentwickeln. Ja und dann ist die Frage, rentiert sich das hinten raus, wenn dann beide quasi wieder dran arbeiten können, würden ja jetzt viele sagen ja auf jeden Fall ich meine eine Woche einarbeiten, danach 2 Leute die durcharbeiten aber das ist ja nicht gegeben, dass es so läuft
plus. Gesagt haben, dieser organisatorische Aufwand, irgendwann musst du ja Leute abstellen, die nur noch managen. Und dann fällt diese Leistung auch wieder weg und ich finde, dann kommt man relativ schnell in den Hamsterrad und Frust kommt auf.
Zum Beispiel angenommen Du bist ein Entwickler von also Vollblutentwickler und auf einmal bist du mehr mit organisatorischen Themen beschäftigt als zu entwickeln, dann dann kommen ja auch so Frust Faktoren schnell ins Spiel. Gut unterbinden muss also unterbinden im Sinne von irgendwie lösen muss und das sind das ist halt so er das kann halt ein richtiger Teufelskreis werden. Aber man sagt ja auch, es gibt
ja auch. So ein Spruch, der da heißt, so bevor es sag ich mal schneller wird, wird es erstmal auf jeden Fall langsamer und ich glaube zwar schon, dass man sagen kann, also in unserem Beispiel unserem Szenario, dass wir gerade mal so ein bisschen gebildet haben, dass man sagt, okay, man möchte jetzt zum Beispiel aus einem Team von 4 Leuten, das möchte man vielleicht verdoppeln, weil noch mehr Sachen zu tun sind, dann würde ich sagen, ist am Anfang definitiv erstmal Fakt,
dass die der Fortschritt der Entwicklung. Was auch immer da entwickelt wird, sagen wir mal irgendeine Software n Produkt wird erst mal langsamer und danach kann ich mir durchaus vorstellen, dass zum Beispiel von wenn du von 4 auf 8 Personen gehst, dass es danach sozusagen schneller
voranschreitet. Das heißt, die Entwicklung kann durchaus schneller werden, ich würde aber nicht sagen, wenn du jetzt zum Beispiel von 4 auf 8 Personen gehst, dass du dann sozusagen deine Entwicklungszeit halbierst.
Das ist zum Beispiel, das sind 2 Punkte, die ich, glaube ich, einfach mal so jetzt in den Raum stellen würde und sagen würde, ich vermute, das ist so. Aber das ist, das ist wirklich eigentlich schon fast eine coole Zusammenfassung von dem, was wir besprochen haben, weil natürlich, wenn ich mehr Entwickler habe und das irgendwann eingespielt ist und jeder einen guten Job macht, kriege ich ja mehr Manpower zusammen und kann schneller entwickeln.
Die Frage ist aber beziehungsweise das Problem an der ganzen Sache ist, dass sowas ja oft entschieden wird, wenn Not am Mann ist, also sprich Zeitdruck aufkommt. Und wie du schon meintest, man wird erst langsamer um dann schneller zu werden. Ist ja quasi gegeben dadurch was was ich zum Beispiel gerade meinte mit dem Einarbeiten, dass du erstmal Leute abstellen musst um neue Leute einzuarbeiten, das ist ja quasi die, also daraus resultiert.
Ja, dass man langsamer wird. Und meistens ist es so, bevor man dann richtig Fahrt aufnehmen kann, ist die Deadline doch dann schon gerissen. Ja, also das ist ja genau der Punkt, man ist da nicht im halben Jahr fertig, nein, vielleicht ist man auch nicht viel schneller als ein Jahr wie es ursprünglich war. Man muss dann halt langfristiger denken und sich also sich überlegen. OK, aber wenn ich diese Leute dabei hab, kann es zukünftig
schneller werden. Ja, aber ich glaube auch nicht, dass du das linear sehen kannst im Sinne von na ja, jetzt 2 und dann sind wir. Also doppelt so schnell. Ja, das funktioniert halt auf keinen Fall meiner Meinung nach, nee. Also das denke ich auch, dass Lini also linear wird es nicht sein. Ich würde auch sagen, dass es irgendwann einen Punkt gibt, wo es wieder schlimmer wird, deswegen würde ich auch zum
Beispiel schon sagen. Eine gewisse Anzahl teamgröße, da sollte nicht unbedingt überschritten werden. Wenn man sich jetzt hinstellt und sagt, Na ja, komm, aber wir haben jetzt zum Beispiel n weiß nicht n Riesen. Projekt, wo ganz viele Leute mitarbeiten.
Dann würde ich wahrscheinlich vorschlagen zu sagen, OK, dann versuchen wir das in einzelne Module zu unters unterteilen, sodass man halt sagt, man hat wieder kleinere Teams, die miteinander arbeiten können und der, ich sag mal die Schnittstelle zwischen den Teams sollte möglichst gering bzw möglichst leichtgewichtig. Sein aber.
Ist ja quasi auch der agile Ansatz, der ja auch in vielen Unternehmen verfolgt wird zu sagen, OK, wir haben wieder kleinere Teams, zum Beispiel Scrum Teams, ja die dann halt wirklich. Super effizient an ihren Themen arbeiten können und. Dann sind das umgesetzt werden kann. Das ist meine. Frage, Da hatten wir auch ne Folge zugemacht.
Da steht wieder auf einem anderen Blatt, aber das ist ja der Sinn dahinter im Prinzip und dann müssen halt die Schnittstellen, wie du schon gesagt hast leichtgewichtig gehalten werden. Zu dem ganzen Thema gibt es ganz witzig wusste ich nicht. Das ist ein bisschen recherchiert worden jetzt von uns. Fand ich ganz witzig, gibt es ja das sogenannte Brooksche Gesetz, was ja im Endeffekt besagt, dass wenn man.
Quasi Manpower zu einem Projekt, was schon verspätet ist, hinzufügt, dass es dann noch später wird. Und das deckt sich halt eigentlich ganz geil mit dem, was wir hier quasi besprochen haben, weil das auch einfach unsere Erfahrung ist. Also es ist keine Lösung zu sagen, Oh, wir haben Zeitdruck, jetzt alle Leute da drauf, dann dann bremst du dich selbst komplett auf 0. Quasi dieses edding menpower to late project, make up make it
even later. Ich find, das klingt homo, klingt so schön auf Englisch irgendwie, aber ich fand es auch cool. Also wir haben jetzt kurz vor der Folge, irgendwie sind wir drauf gestoßen, fand ich auch irgendwie super interessant, das ist überhaupt solche Gesetze gibt finde ich halt schon witzig.
Aber ich würd prinzipiell glaub ich in dem ganzen Zusammenhang sagen, es ist also so. Zusammengefasst würd ich sagen es ist gut, also Teams nicht zu groß zu halten, das heißt möglichst n kleinen Rahmen abzustecken.
Ich würde so weit gehen, dass man sagt, wenn man ein größeres Team bis zu einem bestimmten Rahmen, wie ich gerade meinte, hat, dann kann man die Entwicklung auch erhöhen, also die Entwicklungszeit verkürzen, dass man halt die Geschwindigkeit erhöhen, dass man halt eben sagt, Okay nehmen wir 6 Entwickler, sind wir schneller als 2 Entwickler, wenn man damit startet, beispielsweise wenn man aber jetzt zum Beispiel sagt Okay, um das noch ein bisschen
zusammenzufassen, wir sind mitten im Projekt und wollen jetzt auf einmal mehr Leute hinzufügen, dann kann es halt dazu kommen, dass man, bevor man schneller wird, doch erstmal langsamer wird, wenn man sich wie gesagt in dem Rahmen eines. Kleinen, kleinen Teams bewegt. Und was würdest du jetzt abschließend sagen? Mehr Entwickler machen das Projekt schneller. Mythos oder Fakt?
Ich würde sagen, it depens it. Also wenn man jetzt davon ausgeht, dass man sagt, OK, für jeden Entwickler oder Entwicklerin, die man ins Team hinzufügt, hast du quasi einen linearen Anstieg der Geschwindigkeit. Wenn man das sieht würde ich sagen, ist es absolut ein Mythos und kann man so nicht rechnen, kann man so nicht sehen, wenn man aber davon ausgeht zu sagen, wir nehmen eine vielleicht maximale Teamgröße und gehen davon aus, dass wir von dem
Projekt anfangen. Hatten kann man in gewissen Grenzen sagen. OK, mehr Leute können eine schnellere Geschwindigkeit bringen, aber nicht linear würde ich sagen. Ja, gehe ich mit. Also für mich ist es auch mehr ein Mythos als n. Fakt. Ja.
Aber wie gesagt, klar, wenn ich alleine bin und noch ne zweite Person bekomme, gerade so am Projekt anfangen, macht das auf jeden Fall viel schneller und dann skaliert das bis zu einem gewissen Punkt haben wir ja besprochen, bin ich ganz bei dir, nur dass das immer linear funktioniert ist für mich auch ein absoluter Mythos, das glaube ich nicht und ich?
Glaube, dass viele Leute, die diese Gedanken anstellen, und da stelle ich jetzt mal ganz frech, würde ich einfach sagen, so okay ich glaube, dass einige denken, dass es so ist. Na ja, das war jetzt schon ganz schön frech. Wenn man sagen. Hören. Sagen. Ja, ich würd sagen. Liebe Zuhörerin, lieber Zuhörer. Teil uns doch gerne mal deine
Meinung mit. Vielleicht hast du auch ähnliche Erfahrungen gemacht oder auch vielleicht komplett gegensätzliche und hast festgestellt, ja mehr Leute und alles ging völlig durch die Decke von der Geschwindigkeit her, dann schreib uns doch gerne und melde dich bei uns entweder auf den anderen Plattformen oder per Mail die links findest du wie immer in den Shownotes würde uns auf jeden Fall sehr interessieren, vielleicht bist du auch im Projektmanagement
tätig und weißt wie solche Sachen genau berechnet werden, vielleicht werden da ja noch gewisse Faktoren berücksichtigt, wäre auf jeden Fall auch mal sehr spannend zu erfahren also. Sagt, melde dich gerne bei uns. Ansonsten hoffen wir dir hat die Folge gefallen. Unser kleiner Talk über Mythos oder Fakt im Sinne von mehr Entwickler, schnellere Entwicklung. Und ansonsten macht ihr noch einen schönen Tag. Wir hören uns beim nächsten Mal wieder deine Coding Buddies. Gemeinsam besser.