Habt ihr sowas schon mal gemacht/gehört? Also jetzt nicht in einzelnen Modulen, sondern wirklich gemeinsam vor einem ziemlich grossen Bildschirm am selben Quelltext? Ich konnte mir das überhaupt nicht vorstellen, aber das geht. Die Leute waren locker drauf, haben dabei miteinander über das Programm/Algorithmen gesprochen und natürlich auch privates Gesabbel, Witzchen, Erlebnisse etc. Tenor: -Fehlerquote/Debugaufwand enorm gesunken -insgesamt wesentlich verkürzte Entwicklungszeiten und effizientere Software -kaum Verrennen in Sackgassen -deutlich mehr Kreativität einfach durch das nebenher drüber reden, Variantenabschätzungen schneller erledigt -kein Problem, wenn mal einer ausfällt -weniger Druck wenn Termine/Meilensteine anstehen Klar muss die Mentalität passen, und nicht jeder ist dafür geeignet. Ist aber schon eine mittelgrosse Softwareschmiede, und die machen das seit 3 Jahren so.
:
Verschoben durch User
Tippt dann aber nur einer gleichzeitig? Und die schaffen damit wirklich mehr als wenn die jeweils einzeln an drei unterschiedlichen Programmteilen parallel arbeiten würden? Weil sonst wäre das ja ineffektiv da 3 Mitarbeiter den Job von einem erledigen...
H.Joachim S. schrieb: > Habt ihr sowas schon mal gemacht/gehört? Zu dritt nicht, aber paarweise ist bekannt: "Pair Programming" als Bestandteil der agilen Vorgehensweise "Extreme Programming". Die Idee dahinter ist, dass man Fehler, die beim Codieren nicht gemacht werden, auch nicht suchen und beseitigen muss.
Funkenflug schrieb: > Tippt dann aber nur einer gleichzeitig? > Und die schaffen damit wirklich mehr als wenn die jeweils einzeln an > drei unterschiedlichen Programmteilen parallel arbeiten würden? > Weil sonst wäre das ja ineffektiv da 3 Mitarbeiter den Job von einem > erledigen... Bei manchen kommt es eben auf Qualität statt Quantität an.
H.Joachim S. schrieb: > Habt ihr sowas schon mal gemacht/gehört? Alter Hut. Und ich bin nicht mal Softwerker.
Pair Programming oder wie in diesem Fall "Triple Programming" (ich nenne das jetzt mal so) kann funktionieren, wenn z.B. Algorithmen etc. implementiert werden sollen. Beim Debuggen oder simplen Code runterhacken finde ich es persönlich grauenhaft. Beim Debuggen läuft meistens es so, dass man versucht die vertrackte Logik eines Bugs auf die Schliche zu kommen und wird unterbrochen von den Ideen des anderen, ohne erst einmal die eigene Idee brauchbar verifizieren zu können. Wenn man allerdings glaubt den Fehler gefunden zu haben und den anderen Fragen kann, ob das gleiche Ergebnis herausgekommen ist, dann ist es wieder gut. Hilft zuweilen auch, vergessene Nebeneffekte im Blick zu behalten. Beim Code runterhacken, z.B. UI nach Vorgaben des Designers umsetzen, nervt es zuweilen auch, weil hier je nach Technologien mehrere Wege nach Rom führen und die Diskussion zuweilen unfruchtbar werden. Der eine Programmierer macht es lieber so, der andere lieber so. Ja, schön.
Das Problem in der Praxis ist doch eher, dass es zu zweit schon schwierig genug ist (menschlich & fachlich zusammenpassen, auf den anderen konzentrieren, Gedankengänge nachzuvollziehen, Bewegungen auf dem Bildschirm abzustimmen ...) Bei 3 dürfte es noch seltener passen. Schön wenns klappt, aber forcieren würde ich das nun nicht unbedingt. Außer in einer rein kreativen Phase, mit Beamer, wo es mehr um Konzepte und Ideen geht und nicht so sehr um endgültigen Code. Oder nach dem Codieren, wenn dieser funktional fertig ist und es um Validierung geht, oder um ein gemeinsames Gefühl für Refaktoring zu gewinnen (Namenskonventionen, Layout, Schnittstellenentwurf, ...). Hier auch mit Beamer.
War früher nicht so selten. An der Uni gab es nun mal nicht für jeden ein eigenes Terminal.
Hi Nur ob es ein 'nun will ich aber' statt einem 'nene, mach Du Mal weiter ... Zzzzz ... Zzzzzz' wird macht den Unterschied. MfG
Ob man wohl komplizierte Konzepte ausarbeiten kann wenn man jedes Gedankenschrittchen den anderen erläutern muss, und denen außerdem noch erklären muss warum deren Ideen nicht funktionieren?
Ja, das kann man. Dabei endet die Umsetzung dann nicht in vor lauter Betriebsblindheit überkompliziertem Gefrickel, das hinterher keiner versteht. Code, der so kompliziert ist, dass man ihn nicht erklären kann, ist sowieso wertlos. Alleingänge sind auch beim pair programming OK, wenn man sie hinterher erklärt.
A. N. schrieb: > Beim Debuggen oder simplen Code runterhacken finde ich es persönlich > grauenhaft. Kommt auf den Bug drauf an. Manchmal reicht es schon, den Bug dem Kollegen oder der Gummiente zu erklären: https://en.wikipedia.org/wiki/Rubber_duck_debugging Gruß Roland
Ich nehme an ihr macht erst mit Bleistift etc. eine Übersicht was das Programm können soll und danach auch auf Zettel mit Stift einen Programmablaufplan. Am Ende wird daraus ein Programm in den Rechner getippt in der Programmiersprache eurer Wahl. Oder tippt ihr gleich in den Rechner ?
Zum Programmieren oder Schaltung entwickeln braucht ich immer volle Konzentration. Würde da noch einer reinquatschen, sinkt die Effektivität und die Fehlerquote steigt. Bei 3 wäre es noch schlimmer. Im 3-er Team könnte man bestenfalls den Programmablaufplan rudimentär erstellen, aber nicht sorgfältig und fehlerarm programmieren. Ich finde es immer wieder frustrierend, wie wenig bei Meetings raus kommt. Es wird 1h geplant, dauert aber 2h und alle reden nur um den heißen Brei. Teilt man ein Projekt auf 3 Personen auf, erreicht man bestenfalls die doppelte Produktivität, wie bei einer Person, weil der dritte voll für die notwendige Kommunikation und Koordination drauf geht. Viele Köche verderben den Brei!
:
Bearbeitet durch User
Hier kann man wieder mit einem entschiedenen "Kommt darauf an" antworten. Unser Team betreibt immer wieder mal Pair Programming, aber mit definierten Dos and Don'ts, denn davon hängt Erfolg oder Misserfolg ab. Und ja, richtig angewandt, senkt es die Fehlerrate und man spart sich Debuggingaufwände und auch die von vornherein entstehende Qualität wird gesteigert, weil nicht erst jemand sein Scheiß so runterprogrammiert wie er sichs denkt und man das hinterher wieder mühsam refactoren muss. Pair Programming ist ein Tool wie jedes andere, man muss halt wissen wozu es gut ist, wann man es anwendet und wann nicht. Wenn wir es anwenden, kümmert sich der aktive Part vorrangig um die Lösung des Problems während der passive Part vorrangig die Einhaltung der Rahmenbedingungen (Coding Guidelines, Architekturvorgaben, Sprachbesonderheiten) überwacht, deren Verletzung dann spätestens beim Code Review gerade gezogen werden müssten.
Mit Dingen wie Etherpad kann das ganz gut sein, wenn die Leute nebeneinander sitzen.
H.Joachim S. schrieb: > Also jetzt nicht in einzelnen > Modulen, sondern wirklich gemeinsam vor einem ziemlich grossen > Bildschirm am selben Quelltext? Es geht schon damit los, das Menschen unterschiedliche gute Augen haben. Dem einen ist die Schrift zu klein, dem anderen zu groß oder Schriftart, Helligkeit, Kontrast und Farben zu anstrengend. Auch ist es anstrengender, ständig schräg auf den Schirm schauen zu müssen. Ich bevorzuge in der Konzeptionsphase außerdem die Bleistift+Papier Methode, d.h. Bildschirm aus. Meine Krakeleien sind darauf optimiert, daß ich sie selber gerade noch lesen kann. Nach dem Coden zerknülle ich sie.
H.Joachim S. schrieb: > -deutlich mehr Kreativität einfach durch das nebenher drüber reden, Nach meinen Erfahrungen benötigt Programmieren nur sehr wenig Kreativität (zeitlich gesehen), dafür aber viel Fleiß, Sorgfalt und Genauigkeit. Von der Idee im Kopf bis zum perfekt laufenden Programm, ist es oft ein sehr langer Weg.
:
Bearbeitet durch User
Paul A. schrieb: > Mit Dingen wie Etherpad kann das ganz gut sein, wenn die Leute > nebeneinander sitzen. Löst schonmal das Problem der unterschiedlichen Sehstärken und Sehgewohnheiten.
H-G S. schrieb: > Ich nehme an ihr macht erst mit Bleistift etc. eine Übersicht was das > Programm können soll und danach auch auf Zettel mit Stift einen > Programmablaufplan Das ist nicht Dein Ernst, oder? Diese Bleistift-Metapher kommt aus dem Schulaltag, wo Anfänger eine Programmieraufgabe lösen sollen, in einer Sprache, die sie noch nicht sprechen. Echte Projekte haben einen riesigen und bekannten Kontext. - Beteiligte mit Programmiererfahrung und rudimentärer Kenntniss der Programmiererfahrung (also Stärken und Schwächen der anderen) - Kenntniss bisheriger ähnliche Projekte, Konkurrenzprodukte - Anforderungserhebungen (Voice of Customer, Neue Ideen, Einsatzerfahrungen der Vorgängerprodukte, ...) Unter Erfahrenen Programmierern hat jeder seine eigenen Hilfsmittel. Die einen machen Mindmaps, die anderen Bleistift-Skizzen, andere Schreiben in Word, UML, Visio, an Whiteboards oder Pseudocode. Allen gemeinsam seit den ersten Hochsprachen jedoch ist, dass die Formulierung in echtem Code-Fragmenten meisten viel präzieser ist als in UML oder Bleistift. D.h., solange erfahrene Programmierer unter sich sind, ist die sofortige Fixierung in (Wegwerf-)Code oftmals effektiver als in ausgefuchsten Skizzen. Natürlich werden vorher und währenddessen Dinge auf Papier oder Whiteboard veranschaulicht, allein um sie zu referenzieren zu können (Anker), aber das sind allenfalls abstrakte (vage) Schmierzeichnungen. UML & Co kommen vor allem dann zum Einsatz, wenn die Programmiersprache dafür keine geeigneten Ausdrucksmittel bereitstellt (was selten der Fall ist und meist nur geringe Teile betrifft), oder die Anforderungen mit Leuten diskutiert werden, die es nicht (mehr) lesen können (was meist der Fall ist). Oder wenn es halt genau um die visuellen Teile geht (Bedienung, Auswahl, ...)
Achim S. schrieb: > Echte Projekte haben einen riesigen und bekannten Kontext. Ich würde auch gerne mal den Idealfall haben, daß ein Projekt so vollständig beschrieben ist, daß man es ohne weitere Rückfragen ausprogrammieren kann. Es mag solche Projekte geben, die sind mir aber noch nie untergekommen. Man kriegt eine nur grobe Aufgabe "Steuerung einer Ionenquelle" und muß dann erstmal die Bedienung und Abläufe selber ausarbeiten. Oft wird das dann gegengezeichnet, ohne es richtig gelesen oder verstanden zu haben und dann sind noch umfangreiche Nacharbeiten nötig. Man versucht also in der Implementierungsphase, Sachen universell und leicht änderbar zu gestalten. Ich habe also beim Start nichts konkretes, was man direkt programmieren könnte und daher nehme ich erstmal Papier und Bleistift. Auch beim Implementieren von ICs, z.B. ADCs und DACs muß man sich erstmal aus den Datenblättern mühsam ein Grundverständnis herausklauben und die Abläufe klarmachen. Datenblätter sind in der Regel nicht so verfaßt, daß man danach direkt programmieren könnte. Man muß auch erstmal vor dem Code einhacken umfangreiche Berechnungen ausführen (Meßbereiche, Spannungsteiler, Verstärkungsfaktoren, Taktfrequenzen, Delays usw.) um die IC-Parameter einzuhalten. Der Vorteil ist aber auch, daß man dabei viel Kreativität einbringen kann, statt nur stur runter zu programmieren. Und man kann gut einschätzen, was muß die Hardware machen und was kann man in Software auslagern. Software hat ja den Vorteil, daß sie keine kalten Lötstellen kennt und keine Bauteilkosten. D.h. je weniger die Hardware machen muß, umso höher ist die Zuverlässigkeit und umso geringer sind die Gerätekosten. Ich hab das oft erlebt, als ich noch nicht die Hardware nahe Programmierung gemacht habe, daß unnötig viel in Hardware gefordert wurde, was nur wenige Zeilen Software gekostet hätte, wenn der Programmierer die Hardware nur besser verstanden hätte.
:
Bearbeitet durch User
Peter D. schrieb: > daß unnötig viel in Hardware gefordert > wurde, was nur wenige Zeilen Software gekostet hätte, wenn der > Programmierer die Hardware nur besser verstanden hätte. Ich kenn das nur umgekehrt: "Wir haben die Sensoren an irgendwelche Mikrocontroller-Pins angeschlossen, als Spannungsteiler haben wir die Widerstände genommen die gerade herumlagen, der relevante Bereich der Messung liegt in einem besonders flachen Teil der Übertragungskurve sodass von den 12 ADC-Bits nur noch 5 nutzbar sind, welche Sensoren das genau sind weiß keiner aber es sind auf jeden Fall solche dass ein Kabelbruch nicht von einem sicheren Wert unterschieden werden kann und außerdem sind die so krumm eingebaut dass der Messbereich völlig verschoben ist. Bitte auswerten und in SI-Einheiten ausgeben." Manchmal ist etwas mehr Hardware-Aufwand nicht verkehrt...
>Programmieren zu dritt?
Man kann zusammen singen, aber nicht zusammen programmieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.