Forum: Ausbildung, Studium & Beruf Gibts bei euch Pairprogramming


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Generalkonsul (Gast)


Lesenswert?

https://en.wikipedia.org/wiki/Pair_programming

Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf 
der Pelle hocken muss? Oder andersrum, haben schon solche "Paare" 
geheiratet?

Gibts auch Gang Programming?

Die IT-Welt wird immer perverser.

von Q.B-Qwertzberater (Gast)


Lesenswert?

Nö.
Bin ich auch nicht sonderlich traurig drüber.

Kann ich wenigstens unbeobachtet bei der Arbeit im Inet Surfen :D

von A. S. (achs)


Lesenswert?

Generalkonsul schrieb:
> Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf
> der Pelle hocken muss? Oder andersrum, haben schon solche "Paare"
> geheiratet?
>
> Gibts auch Gang Programming?
>
> Die IT-Welt wird immer perverser.

Ich habe das ein Jahr gemacht. Aber freiwillig, weil es passte. Und nur 
dann geht das m.E. auch. Ganz klassisch, ein junger und ein erfahrener 
als Zweier-Team, so Watson - Crick. Kam natürlich, wie es kommen musste, 
nach dem Jahr war Crick aus der Firma gemobbt.

Bei den Beschreibungen von VW handelt es sich m.E. eher um ein Modell, 
geregelte Arbeitszeiten und gegenseitige Kontrolle über diesen "hippen" 
Style zu etablieren. Mit jungen Leuten ohne work-life-balance kann man 
das machen.

Beitrag #6741071 wurde von einem Moderator gelöscht.
Beitrag #6741102 wurde von einem Moderator gelöscht.
von Max der Hochstapler (Gast)


Lesenswert?

Zum Glück nicht. Bleib mir weg mit dem Scheiss. Mir reicht schon, dass 
wir jetzt ein Großraumbüro eingeführt haben und mir alle Kollegen im 
Nacken auf den Monitor gaffen können. Für mich ein Kündigungsgrund.

von Reinhard S. (rezz)


Lesenswert?

Max der Hochstapler schrieb:
> Zum Glück nicht. Bleib mir weg mit dem Scheiss. Mir reicht schon, dass
> wir jetzt ein Großraumbüro eingeführt haben und mir alle Kollegen im
> Nacken auf den Monitor gaffen können. Für mich ein Kündigungsgrund.

Geh halt ins Homeoffice, da kannst du weiterhin unbeobachtet rumdaddeln 
:D

Aber wer führt denn in Corona-Zeiten Großraum ein?

von Anita H. (anita1995)


Lesenswert?

Generalkonsul schrieb:
> https://en.wikipedia.org/wiki/Pair_programming
>
> Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf
> der Pelle hocken muss?

Mir würde es gefallen :-)

Der eine oder andere wäre es mir schon wert auf meinen Stuhl zu 
verzichten...
Blöd nur wenn der Chef reinkommt, oder seine Frau :-D

von HP-CodeGrinder (Gast)


Lesenswert?

Ich habe schon vor Y2K Pairprogramming praktiziert und dabei von 
gewissen Vorteile davon gut profitiert.

Der Merksatz lautet ungefähr: «4 Augen und 4 Hirnhälften am selben 
"Werkstück" erreichen mehr als bloss 2 Augen und 2 Hirnhälften»

Ohne Preis geht das nicht:

- die 2 welche das "Pair" bilden müssen sich ertragen/mögen (können) 
(keine sozialhandicappierte Mimöschen sein),

- das dabei erreichte Konzentrationsniveau ist hoch und zermürbend (d.h. 
Pairprogramming praktiziert man nur punktuell und pausiert öfters 
dazwischen) Ich jedenfalls errinnere mich ans "Ausgelaugt sein" 
danach...

Dauerzustand über 8h/Arbeitstag KANN NICHT im Modus Pairprogramming 
durchgezogen werden!

Die damit erreichten Erfolge sind aber definitiv positiv UNMATCHED!

Sowohl im Bereich "Erstimplementation", "Architekturumpflügen" wie auch 
"Fehlersuche"; selbstverständlich nicht in der Aufgabenklasse "Hello, 
world!" oder nur in 64kB Adressraum... sondern in Anwendungsfälle welche 
mehr als 16MB RAM erforden und in konkurrierendem Multitasking 
nicht-triviale Datenmodelle beackern.

Beitrag #6741192 wurde von einem Moderator gelöscht.
Beitrag #6741196 wurde von einem Moderator gelöscht.
Beitrag #6741284 wurde von einem Moderator gelöscht.
Beitrag #6741291 wurde von einem Moderator gelöscht.
von Mladen G. (mgira)


Lesenswert?

Pair Programming ist ja sowas von 2012..

https://vimeo.com/41159601

: Bearbeitet durch User
Beitrag #6741301 wurde von einem Moderator gelöscht.
Beitrag #6741305 wurde von einem Moderator gelöscht.
von Roland E. (roland0815)


Lesenswert?

Bei W7 hat M$ das angeblich gemacht. Soll auf Anhieb gute Ergebnisse 
geliefert haben.

Praktisch ist das ein Review gleich beim Erstellen. Kann mir gut 
vorstellen, dass das was bringt.

von name (Gast)


Lesenswert?

Nicht mehr Zeitgemäß, solche Sprüche...

von Manager (Gast)


Lesenswert?

Max der Hochstapler schrieb:
> Zum Glück nicht. Bleib mir weg mit dem Scheiss. Mir reicht schon, dass
> wir jetzt ein Großraumbüro eingeführt haben und mir alle Kollegen im
> Nacken auf den Monitor gaffen können. Für mich ein Kündigungsgrund.

Tschüss

von Falk B. (falk)


Lesenswert?

Roland E. schrieb:
> Bei W7 hat M$ das angeblich gemacht. Soll auf Anhieb gute Ergebnisse
> geliefert haben.
>
> Praktisch ist das ein Review gleich beim Erstellen. Kann mir gut
> vorstellen, dass das was bringt.

Nur weil was gut klingt, muss es nicht auch wirklich gut sein. Siehe 
diverse Ideen und Produktankündigungen von Elon Musk. ;-)

Wenn eine Idee WIRKLICH gut ist, muss sie sich reproduzierbar in der 
harten Realität beweisen und dann auch DEUTLICH sicht- und messbare 
Vorteile bringen.

von Christoph Z. (christophz)


Lesenswert?

> Gibts bei euch Pairprogramming

Leider nein. Ich bin gefühlt der einzige, der bei den anderen hin und 
wieder in die Git commits reinschaut um zu sehen ob da wenigstens 
einigermassen Features und fixes separat commited werden.

Falk B. schrieb:
> Wenn eine Idee WIRKLICH gut ist, muss sie sich reproduzierbar in der
> harten Realität beweisen und dann auch DEUTLICH sicht- und messbare
> Vorteile bringen.

Ja, das wäre gutes Vorgehen. Dafür müsste man vor der Einführung ja 
schon gute Metriken haben über die Produktivität (oder parallel ein 
vergleichbares Team/Projekt als Kontrollgruppe). Und das haben leider 
viele Firmen nicht oder ihre Metriken sind durch "lustige" Regeln 
unbrauchbar gemacht worden (ist bei uns so...).

von Max der Hochstapler (Gast)


Lesenswert?

Christoph Z. schrieb:
> Leider nein. Ich bin gefühlt der einzige, der bei den anderen hin und
> wieder in die Git commits reinschaut um zu sehen ob da wenigstens
> einigermassen Features und fixes separat commited werden.

Und was hat das mit diesem elendigen Pairprogramming zu tun?

von Mladen G. (mgira)


Lesenswert?

Beim Pair Programming geht es nicht darum den Review "zu sparen", der 
sollte sowieso von jemandem gemacht werden der nicht am Code 
mitgearbeitet hat.
"mal in die Git commits reingucken" hat also nix mit Pairing zu tun.

Da geht es darum, gemeinsam an etwas zu arbeiten, mit verschiedenen 
Rollen, aus unterschiedlichen Perspektiven, high-level und im Detail, 
derjenige "der Führt" kümmert sich um die Details, die andere Person 
eher um das high-level Bild.
Damit gibt es schon einen regen Austausch während dem Entwickeln.

Ist auch super um auch neue Leute einzulernen bzw. Wissen zu 
transferieren, etwas über die Code Basis zu lernen und sich ein paar 
Tricks mit der IDE abzugucken.

Pair Programming kommt ursprünglich aus der "extreme Programming" Ecke, 
ist aber mittlerweile sehr normal, so dass da nix mehr "extrem" ist, da 
ist zB. mit CI/CD und TDD auch so.

Mir macht das Spass :)

von Christoph Z. (christophz)


Lesenswert?

Max der Hochstapler schrieb:
> Und was hat das mit diesem elendigen Pairprogramming zu tun?

War ein Beispiel, wie weit weg wir hier von der Denkweise sind, wo man 
überhaupt beginnt über Pairprogramming nachzudenken.

Ordnung halten im Repo? Reviews machen? Schön wärs. (Aber eigentlich 
verlangt in unserer Branche...)

von Grano U. (grano)


Lesenswert?

Hab das vor sieben Jahren einmal gemacht, mit zwei Kollegen, mit denen 
ich auch gut befreundet war. Dabei waren wir nicht zu zweit sondern zu 
dritt. Außerdem haben wir das per Skype mit Screensharing gemacht, damit 
wir uns nicht zu dritt hinter einem Bildschirm quetschen mussten. Die 
Aufteilung war so, dass einer das Tippen übernommen hat (hatte auch die 
Hoheit über Variablennamen und Git-Commits) und die anderen zwei haben 
sich ständig ausgetauscht wegen High-level-Zeugs und haben auch 
angesagt, was zum Tippen ist. Es ist anstrengend, aber dafür war das 
qualitativ guter Code. Die Mentalität war auch so, dass man 
Streitigkeiten vermieden hat und dann einfach gesagt hat, man soll doch 
schnell im Pseudocode zeigen was gemeint ist. Da gab es immer wieder 
Ah-und-Oh-Momente und einen gewissen Lerneffekt.

Dem Kollegen, der die Tests geschrieben hat, hat das auch gefallen, weil 
es kaum Fehler gab und er die Tests in einem Rutsch schreiben konnte, 
ohne auf einen Bugfix von uns zu warten. Der Chefetage hat das nicht 
ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht 
haben.

von Max der Hochstapler (Gast)


Lesenswert?

Mladen G. schrieb:
> Pair Programming kommt ursprünglich aus der "extreme Programming" Ecke,
> ist aber mittlerweile sehr normal, so dass da nix mehr "extrem" ist, da
> ist zB. mit CI/CD und TDD auch so.
>
> Mir macht das Spass :)

Mir nicht.

von TGIF (Gast)


Lesenswert?

Grano U. schrieb:
> Der Chefetage hat das nicht
> ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht
> haben.

Aha. Und welches KPI haben die da in ihrer unermesslichen Weisheit zu 
Hilf genommen?

"Pair Programming" mit mehr als zwei nennt man übrigens "Mob 
Programming" und ist richtig gut.

Komischerweise haben die Chefs nie Probleme damit die Leute Stundenlang 
in irgendwelche bescheuerten Meetings zu setzen.

von Mladen G. (mgira)


Lesenswert?

Grano U. schrieb:
> Der Chefetage hat das nicht
> ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht
> haben.

Das sind Effekte die man bekommt wenn ein paar Hierarchiestufen 
übersprungen werden, aka "micro management", die "Chefetage" hat 
eigentlich andere Aufgaben, ob eine bestimmte Praxis hilfreich ist oder 
nicht, ist eine Teamentscheidung.
Die obere Etage darf sich dann Gedanken machen ob das Team funktioniert 
bzw. die Leistung bringt die es soll.

Das ist nix anderes als wenn der Chef deines Chefs zu dir an den 
Arbeitsplatz kommt und anfängt dir den Code zu diktieren, oder dir ein 
paar extra Aufgaben zuschiesst, das geht komplett am der Teamarbeit 
vorbei.

Schlimmer wird es eigentlich nur mit "Projektmanagern", wenn das Team 
bzw. Individuen im team der Meinung sind dass bestimmte Dinge nicht 
gehen im einem bestimmten Zeitraum, ist die Motivation auch weg, "ich 
hab ja gleich gesagt dass das nicht geht" kann man danach hören, 
sozusagen als Rechtfertigung.

Wenn Teams selber entscheiden und dafür geradestehen, ist das eine ganz 
andere Sache.

Fehler machen ist normal, Menschen lernen durch Fehler die sie als 
solche anerkennen, es geht ja nicht um Perfektion, sondern um stetige 
Verbesserung.

: Bearbeitet durch User
von Grano U. (grano)


Lesenswert?

TGIF schrieb:
> Grano U. schrieb:
>> Der Chefetage hat das nicht
>> ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht
>> haben.
>
> Aha. Und welches KPI haben die da in ihrer unermesslichen Weisheit zu
> Hilf genommen?
keine Ahnung. Vermutlich Bauchgefühl zusammen mit einem Business-Orakel

> "Pair Programming" mit mehr als zwei nennt man übrigens "Mob
> Programming" und ist richtig gut.
Danke. Wusste ich nicht. Mob Programming klingt aber schon sehr 
aggressiv.

von Falk B. (falk)


Lesenswert?

Grano U. schrieb:
>> "Pair Programming" mit mehr als zwei nennt man übrigens "Mob
>> Programming" und ist richtig gut.
> Danke. Wusste ich nicht. Mob Programming klingt aber schon sehr
> aggressiv.

Schon mal was von Sarkasmus gehört?

von Programmierer (Gast)


Lesenswert?

Beim Pair-Programming stört es mich kolossal, ständig alles zu erklären 
"Das ist ein void-Pointer, damit kann man auf beliebige Dinge zeigen", 
"das ist eine globale Variable, die ist schlecht für die Architektur 
weil...", "das ist ein generischer Algorithmus, der ermöglicht 
typsichere Verarbeitung unterschiedlicher Datentypen", "hier haben wir 
eine Race-Condition, da brauchen wir ein Synchronisationsprimitiv, denn 
moderne Prozessoren haben Caches"... Das degeneriert irgendwie immer zu 
einer Vorlesung.

von A. S. (achs)


Lesenswert?

Programmierer schrieb:
> Beim Pair-Programming stört es mich kolossal, ständig alles zu erklären
> "Das ist ein void-Pointer, damit kann man auf beliebige Dinge zeigen",

Das ist nicht pair programming. Das ist Schulung. Und vermutlich Recht 
ineffektiv.

Da ist es besser, 2 Anfänger zusammen arbeiten zu lassen und vieles zu 
übersehen. Auch Fahrradfahren muss man am Ende selber lernen. Und das 
geht ohne gute Ratschläge besser.

Anfänger lässt man innovative Sachen machen, deren Code man am Ende zur 
Not wegschmeißen oder neu machen kann.

von Programmierer (Gast)


Lesenswert?

A. S. schrieb:
> Da ist es besser, 2 Anfänger zusammen arbeiten zu lassen und vieles zu
> übersehen. Auch Fahrradfahren muss man am Ende selber lernen. Und das
> geht ohne gute Ratschläge besser.

Kann gut sein, aber wer das seit 20 Jahren macht wird nicht plötzlich 
anfangen sich selbsttätig einzulernen und mal zu schauen was z.B. ein 
void-Pointer ist.

A. S. schrieb:
> Anfänger lässt man innovative Sachen machen, deren Code man am Ende zur
> Not wegschmeißen oder neu machen kann.

Ich glaub Anfänger programmieren den größten Teil der Software der so im 
Umlauf ist.

von Mladen G. (mgira)


Lesenswert?

Programmierer schrieb:
> Ich glaub Anfänger programmieren den größten Teil der Software der so im
> Umlauf ist.

2018 hab ich auf einem Vortrag gehört dass sich die Anzahl der SW 
Entwickler alle 5 Jahre verdoppelt, d.h. dann dass 50% der Entwickler 
weniger als 5 Jahre Berufserfahrung haben.

Sind zwar keine Anfänger mit 4,5 Jahren Berufserfahrung, aber es sollte 
klar sein warum solche Praktiken wie Pair Programming, Peer Reviews etc. 
Vorteile haben können.

von Oliver S. (phetty)


Lesenswert?

Statt nebeneinander zu glucken geht das heutzutage per Team/Zoom usw. 
doch viel besser.
Man sieht den Bildschirm des anderen, kann auf seinem zweiten Bildschirm 
noch was selber hacken und umgekehrt.

von A. S. (achs)


Lesenswert?

Programmierer schrieb:
> Kann gut sein, aber wer das seit 20 Jahren macht wird nicht plötzlich
> anfangen sich selbsttätig einzulernen und mal zu schauen was z.B. ein
> void-Pointer ist.

Uups, :-( ja, das kenne ich auch )-:

Mit geballten Ratschlägen, was der Compiler falsch macht, so mit immer 
ein else-Zweig sonst spinnt der oder so.

: Bearbeitet durch User
von Programmierer (Gast)


Lesenswert?

A. S. schrieb:
> so mit immer ein else-Zweig sonst spinnt der

Wenn man solche Probleme hat, hat man den falschen Compiler...

von A. S. (achs)


Lesenswert?

Programmierer schrieb:
> Wenn man solche Probleme hat, hat man den falschen Compiler...

nein. Das war von den Kollegen mit 20 Jahren Erfahrung und großen Augen 
wofür void denn gut ist.

Beitrag #6741987 wurde von einem Moderator gelöscht.
von Eulenspiegel (Gast)


Lesenswert?

Generalkonsul schrieb:
> https://en.wikipedia.org/wiki/Pair_programming
>
> Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf
> der Pelle hocken muss? Oder andersrum, haben schon solche "Paare"
> geheiratet?
>
> Gibts auch Gang Programming?
>
> Die IT-Welt wird immer perverser.

Haha, ich hatte das mal bei einem Praktikum.

> A: Hey du, du hast da den Pointer auf die struct nicht dereferenziert, das 
kompiliert nicht mit der Funktion da
> B: Neeeee, ich mach hier mal weiter...<tip tip tip>
> A: Okay
> B: <tip tip tip><ctrl+s><make><ENTER>
> Compiler: ;_;
> A: Na siehst du.
> B: Achja, so war das gemeint.

Jaaaah, sehr produktiv. Und gerade beim Programmieren völlig nutzlos. 
Kritischen Input braucht man in der Designphase und beim Review der 
Implementierung. So drücken 2 quasi zur gleichen Zeit dieselben Tasten 
und merken gegenseitig, was der Compiler auch sofort merkt :/

von ganz doll (Gast)


Lesenswert?

Oliver S. schrieb:
> Statt nebeneinander zu glucken geht das heutzutage per Team/Zoom usw.
> doch viel besser.

Absolut korrekt.

Für die Besitzer von Team/Zoom ist es wirklich viel besser. Die 
Betriebsgeheimsnisse werden direkt frei Haus geliefert.

Beitrag #6742119 wurde von einem Moderator gelöscht.
Beitrag #6742147 wurde von einem Moderator gelöscht.
von René F. (therfd)


Lesenswert?

Generalkonsul schrieb:
> Gibts auch Gang Programming?

Klar, Gang Programmer sind sogar richtig effektiv wenn es um hohen 
Durchsatz geht ;)

von Three Lions on the shirt (Gast)


Lesenswert?

Das ist wieder mal so ein neumodischer Mist. Da sitzen dann zwei Leute 
vorm Rechner, tratschen über Privates und machen die Arbeit von einem. 
Das kann sich auch nur ein Konzern erlauben.

Bei komplexen Themen da holft man sich natürlich Kollegen zur Hilfe oder 
bespricht im Team etwas, vorallem grundlegende Dinge. Das sollte aber 
nur einen kleinen Teil der Arbeitszeit betreffen.

von Three cockroaches on the shirt (Gast)


Lesenswert?

Gute Zusammenarbeit generiert Mehrwert. Verstehen nur Sozialphobiker 
nicht.

von A. S. (achs)


Lesenswert?

Three Lions on the shirt schrieb:
> Das ist wieder mal so ein neumodischer Mist. Da sitzen dann zwei Leute
> vorm Rechner, tratschen über Privates und machen die Arbeit von einem.
> Das kann sich auch nur ein Konzern erlauben.

Im Gegenteil: Da sitzen 2 Leute und kreieren die Architektur des Moduls 
indem sie darüber sprechen und das ganze auch instanziieren. Einer 
Tippt, der andere prüft die Abläufe, Namen und Konzepte entstehen.

Und wenn es nur bessere Namen gibt, lohnt es sich schon. Denn schreiben 
geht schnell, viel öfter und länger wird der Code gelesen.

Beitrag #6742480 wurde von einem Moderator gelöscht.
Beitrag #6742503 wurde von einem Moderator gelöscht.
Beitrag #6742510 wurde von einem Moderator gelöscht.
Beitrag #6742512 wurde von einem Moderator gelöscht.
Beitrag #6742562 wurde von einem Moderator gelöscht.
von doppel (Gast)


Lesenswert?

Ich bin da sehr gespalten was das ganze Pairprogramming angeht.

Es gibt durchaus Phasen wo es sinnvoll ist, wenn zwei drauf schauen. 
Besonders da sehe ich es als sinnvoll an, wenn ein erfahrener und 
unerfahrener Kollege/in zusammenarbeiten. Lernen und Lehren macht mir 
Spaß.

Ich habe dieses Doppel-Bearbeiter Modell auch schon bei anderen Aufgaben 
gesehen und erlebt, z.B. beim langwierigen Ausfüllen komplexer Excel 
Dokumente. Da war es sogar vom Kunden gefordert und bezahlt.
Das war TEILS sinnvoll weil es Fehler vermeidet hat. In vielen Fällen 
aber führt das dazu, dass einer klickt und tippt und der andere mental 
abschaltet bzw. nur noch auf Zuruf denkt. Mir persönlich ist die Rolle 
des Zusehers zu passiv, da fühle ich mich derart unterfordert, dass ich 
mich immer wieder dabei ertappe, über andere Probleme nachzudenken. Wenn 
ich selbst tippe bin ich eher zufrieden.

Alleine(!) am Dokument inhaltlich arbeiten nur nach Genehmigung des 
Kunden erlaubt.

Die Teams wurden bei uns auch relativ wild zusammengewürfelt. Hat 
teilweise schlecht funktioniert, ein "mit X mach ich nix mehr!" war fast 
schon an der Tagesordnung. So etwas verstärkt auch die Grüppchenbildung 
noch mehr.

Je nach Persönlichkeit der Personen macht es letztendlich wieder nur 
einer:
- Du hast einen sehr dominante Person + eine sehr schüchterne Person die 
etwas bewerten sollen. Das Ergebnis ist dann 90%/10% der Meinungen, wenn 
überhaupt.
- Du hast einen der geht dir auf den Sack. Dann hast du keinen Bock zu 
diskutieren. Macht auch wieder so 80%/20%
- Du hast einen der hat keinen Bock auf den Job? Na dann wirds 0%/100%, 
der spielt am Handy während du tippst.


Generalkonsul schrieb:
> Gibts auch Gang Programming?

Natürlich. In Vor-Corona Zeiten waren bei manchen internen Reviews sogar 
drei Leute vorm Rechner. Die zwei ausführenden + nochmal einer zum 
kritisch Drüberschauen. Leider kein Witz.


Das Problem hier ist, dass die GRUNDIDEE eine sehr gute ist, siehe oben: 
Vier Augen sehen mehr als zwei und die Leute lernen was.
Aber die Umsetzung ist falsch. Es wurde einfach die Methode "Pair 
Programming" kopiert, ohne den Mechanismus und die Idee dahinter 
durchdrungen zu haben. Damit kehrt sich das dann ins Gegenteil um. Ein 
echter Zeitkiller mit niedriger Effizienz.

von Prokrastinator (Gast)


Lesenswert?

Pair programming kenne ich anders.

Da bekommt einer die Arbeit von zwei aufgebürdet, was nach Ansicht der 
GF dann auch zu sofortigen guten Ergebnissen und erstklassiger Doku 
führen soll.

Als Mentorenprogramm noch vorstellbar, aber zwei gute Programmierer an 
einer Aufgabe?
Wer hat denn die im Übermaß?

von Mike (Gast)


Lesenswert?

Ich finde das Konzept generell interessant. Wie oft blockiert man sich 
gedanklich oder in der Umsetzung selber. Mit einem Kollegen, der 
hinreichend in den ganzen Gedankengängen steckt und die Software kennt, 
lässt sich so ein Schwebezustand doch viel schneller auflösen als mit 
substanzlosem Palaver....

Oder geht das euch nicht so, dass ihr mal stockt? Man muss sich aber 
ganz bestimmt gegenseitig eingrooven und je nach Alphamännchen kann es 
auch mal mehr mal weniger funktionieren.

Aber ist doch eh nur Theorie. Meine Geschäftsleitung würde nur sehen: 2 
Mitarbeiter für eine Arbeit ist Verschwendung. Da wird nämlich an allen 
Ecken und Enden Zeit verpulvert, leere Besprechungen gahalten, Power 
Points erstellt....aber wenn man konkrete Zahlen von Tagen oder Stunden 
hört die nicht direkt ersichtlich sind, ist das Geschrei groß.

von Senf D. (senfdazugeber)


Lesenswert?

Mike schrieb:
> Meine Geschäftsleitung würde nur sehen: 2 Mitarbeiter für eine Arbeit
> ist Verschwendung. [...]
> aber wenn man konkrete Zahlen von Tagen oder Stunden hört die nicht direkt
> ersichtlich sind, ist das Geschrei groß.

Was habt ihr alle nur für seltsame Chefs?!

von doppel (Gast)


Lesenswert?

Vor allem frage ich mich: Wenn ich das Geld, das ich für zwei schlechte 
bis mittelmäßige Programmierer ausgeben muss, für einen Top-Mitarbeiter 
ausgebe, kommt dann am Ende nicht mehr dabei heraus?

Natürlich ist es einfacher zu sagen, ich brauch da mal zwei 
Programmierer für 60k€ im Jahr, als zu sagen: Ich will da nen 
Spezialisten für 120k€ im Jahr anstellen.

von Programmierer (Gast)


Lesenswert?

doppel schrieb:
> für einen Top-Mitarbeiter ausgebe, kommt dann am Ende nicht mehr dabei
> heraus?

Das Blöde an Top-Programmierern ist, dass sie sich schnell langweilen. 
Wenn man denen einfache Aufgaben gibt, wie sie nun mal im Tagesgeschäft 
vorkommen, bauen die fantastische overengineered Lösung, die dann keiner 
warten kann. Gerade in Deutschland ist es so, dass die allermeisten 
Firmen "nur" gewöhnliche Anwendungen entwickeln ohne große technische 
Herausforderung - Hauptsache, es funktioniert irgendwie. Technische 
Innovation ist ja eher was für die USA oder China. Außerdem könnten die 
Top-Programmierer vor lauter Unterforderung depressiv werden und 
ausfallen oder kündigen. Die normalen Programmierer sind da beständiger. 
Es fährt ja auch keiner mit einem Formel 1-Auto zum Supermarkt, selbst 
wenn die Straßenzulassung hätten - zu dem Preis bekommt man viele 
zuverlässige VW Golf's.

doppel schrieb:
> Ich will da nen Spezialisten für 120k€ im Jahr anstellen.

Das wird in den wenigsten Firmen funktionieren... einen 
Top-Programmierer von einem Blender zu unterscheiden ist auch nicht so 
einfach.

von A. S. (achs)


Lesenswert?

doppel schrieb:
> In vielen Fällen
> aber führt das dazu, dass einer klickt und tippt und der andere mental
> abschaltet bzw. nur noch auf Zuruf denkt.

Eigentlich ist das umgekehrt: Einer Tippt, der andere entwirft. Wenn 
jemand entwirft und eintippt, dann ist der zweite überflüssig, ein Opfer 
oder Zuschauer (es gibt Leute, eher Handwerker, die können nur arbeiten, 
wenn sie dabei anderen erzählen, was sie alles machen).

Ist ja oft woanders auch, einer misst, der andere notiert. Einer 
erzählt, der andere schreibt mit. Nicht nur passiv, sondern als aktiver 
Zuhörer/Journalist/Qualitätsbeauftragter/Prüfingenieur.

von Uwe D. (monkye)


Lesenswert?

Also ich persönlich finde es nicht schlimm, den Gedanken an sich nicht 
zu mögen. Aber einige Beiträge sind einfach nur plump, missgünstig, 
arrogant und zeugen von Unerfahrenheit/Überheblichkeit.

Jede/r der große und/oder komplexe Software entwickelt hat erfahren, 
dass das Gesamtergebnis nur so gut sei kann, wie es der Schwächste unter 
den Entwicklern ist.
Und Qualität kann man messen und spielen kostenseitig eine große Rolle.

Wie heißt es so schön? "Entdecke die Möglichkeiten..."

PS: Auf dem Fußballplatz trainieren auch nicht die D-Mannschaft und die 
Bundesliga gemeinsam... Das Setting bekommen gute Führungskräfte locker 
hin.

von P. P. (klatschnass)


Lesenswert?

Für das normale Runterprogrammieren von Standardaufgaben braucht man 
meiner Meinung nach nicht unbedingt zusammenzusitzen.
Interessant wird es eher bei:
- neuen Technologien
- Fehlersuche
- Performanceverbesserungen
- Multithreading

Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann 
jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code 
schreibt.

Interessant finde ich den Ansatz, das Programmieren durch einen KI-Bot 
zu unterstützen:
https://www.golem.de/news/machine-learning-github-bringt-ki-bot-copilot-zum-programmieren-2106-157750.html

: Bearbeitet durch User
von Reinhard S. (rezz)


Lesenswert?

P. P. schrieb:
> Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann
> jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code
> schreibt.

Klingt eher nach schmoren im eigenen Saft.

von Im Mittel legt der Deutsche gleich morgens 2 Eier (Gast)


Lesenswert?

P. P. schrieb:

> Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann
> jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code

Das entspricht nicht meiner Realität. Mein KI-Bot meldet Fake-News.

von Djangos_zahnarzt (Gast)


Lesenswert?

Mache das im Rahmen der Einarbeitung mit neuen Kollegen damit Sie 
schneller effektiv selber arbeiten. Ist anfangs völlig in Ordnung und 
spart Kosten. Softwareentwicklung ist Team Sport, weil es um die 
gemeinsame Verständnis und Lösung von Problemen geht.

von A. S. (achs)


Lesenswert?

Djangos_zahnarzt schrieb:
> Mache das im Rahmen der Einarbeitung mit neuen Kollegen damit Sie
> schneller effektiv selber arbeiten

Ui, dass stell ich mir aber extrem belastend vor. Ihm was zeigen oder er 
Dir, geschenkt. Aber während der Einarbeitung permanent sozialer Stress, 
... .

Pair-Prigramming ist wie an einer Tafel eine Formel oder ein Konzept zu 
erstellen. Deins hört sich eher an, wie in der Klasse an die Tafel zu 
müssen.

: Bearbeitet durch User
von wieder mal ein Sonderweg (Gast)


Lesenswert?

Wikipedia:

(pair programming) ... ist ein wichtiger Bestandteil von Extreme 
Programming (XP).

....Einer schreibt den Code, während der andere über die 
Problemstellungen nachdenkt, den geschriebenen Code kontrolliert sowie 
Probleme, die ihm dabei auffallen, sofort anspricht. Diese können dann 
sofort im Gespräch gelöst werden. Die beiden Programmierer sollten sich 
in den beiden Rollen abwechseln.


-------

Die Betreuung von Anfängern ist kein pair programming.

Beitrag #6747840 wurde von einem Moderator gelöscht.
von meckerziege (Gast)


Lesenswert?

Reinhard S. schrieb:
> P. P. schrieb:
>
>> Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann
>> jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code
>> schreibt.
>
> Klingt eher nach schmoren im eigenen Saft.

Exakt. Teils ist das auch gar nicht zulässig. In der Luftfahrt zum 
Beispiel ist bei manchen Anforderungen bzw SW explizit gefordert dass 
diese unabhängig vom ursprünglichen Entwickler geprüft wird.

Für den meisten anderen Code ist das auch sehr sinnvoll, sofern 
wirtschaftlich vertretbar.

von A. S. (achs)


Lesenswert?

meckerziege schrieb:
> Für den meisten anderen Code ist das auch sehr sinnvoll, sofern
> wirtschaftlich vertretbar.

(eigene) Tests sind nie eine Lösung, sondern maximal ein 
Programmierparadigma:  Wenn die gleiche Person Tests und Code schreibt, 
dann

a) werden Verständnisfehler des Programmierers nicht erkannt
b) führt das zu Minifunktionen bei mehr Aufrufebenen und mehr code (bzw. 
zu aufwändigeren Integrationstests)
c) führt die redundante Programmierung (Test und Code beschreiben ja 
spiegelbildlich das gleiche) schnell zur Nachlässigkeit. Man ist eigenen 
Fehlern ("ah, mit <= geht es, mit < nicht --> dann <=") gegenüber oft 
viel toleranter ;-)

von F. B. (finanzberater)


Lesenswert?

A. S. schrieb:
> (eigene) Tests sind nie eine Lösung, sondern maximal ein
> Programmierparadigma:  Wenn die gleiche Person Tests und Code schreibt,
> dann

Ich kann nur sagen: Der Code derjenigen Kollegen, die immer am 
vehementesten automatisierte Softwaretests gefordert haben, der hatte 
die meisten Bugs. Warum? Weil ihre Tests ja grün waren. Deswegen hielten 
sie es nicht mehr nötig, manuell zu testen. Von diesem ganzen Humbug, 
automatisierte Softwaretests würden Zeit sparen, will ich erst gar nicht 
anfangen. Für jede Codeänderung müssen auch die Tests nachgezogen 
werden. Also jedes Mal doppelte Arbeit. Es gibt nur wenige Ausnahmen, in 
denen Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle 
Testen sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur 
Backend programmiert und wegen fehlender UI keine manuellen Tests 
möglich sind.

: Bearbeitet durch User
von mh (Gast)


Lesenswert?

F. B. schrieb:
> Es gibt nur wenige Ausnahmen, in denen
> Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle Testen
> sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur
> Backend programmiert und wegen fehlender UI keine manuellen Tests
> möglich sind.

Wenn du von "wenigen Ausnahmen" sprichst, meinst du dann Kategorien oder 
was? Was ist manuellem Testen? Auf Knöpfe in der GUI klicken? Was genau 
meinst du mit UI? Eine GUI?

Was ich mir unter manuellem Testen vorstelle, ist bei nicht trivialer 
Software immer aufwendig, komplex und fehleranfällig.

von A. S. (achs)


Lesenswert?

F. B. schrieb:
> Es gibt nur wenige Ausnahmen, in
> denen Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle
> Testen sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur
> Backend programmiert und wegen fehlender UI keine manuellen Tests
> möglich sind.

Wo TDD richtig gut ist: komplexe Funktionen mit wenigen Ein- und 
Ausgaben. Standard-Beispiel sind Mathematische Funktionen, z.B. sin oder 
sqrt: Zwei Zahlen, komplexer Code, Sonderbehandlungen (NaN und so), aber 
sehr genau in wenigen Sätzen formulierbar, was passieren soll.

In der Praxis ist es meist umgekehrt: Abgesehen von trivialen 
Mini-Funktionen gibt es einen umfangreichen Kontext (was äquivalent zu 
Ein- und Ausgaben ist) und einfache, aber viele Abhängigkeiten. Und je 
mehr man die Abhängigkeiten zerfasert, umso eher sind Kontrollfluss und 
Kontext futsch (hidden), geopfert einer Testbarkeit bedeutungsloser, 
sinnentstellter Partikel.

von mh (Gast)


Lesenswert?

A. S. schrieb:
> Wo TDD richtig gut ist: komplexe Funktionen mit wenigen Ein- und
> Ausgaben. Standard-Beispiel sind Mathematische Funktionen, z.B. sin oder
> sqrt: Zwei Zahlen, komplexer Code, Sonderbehandlungen (NaN und so), aber
> sehr genau in wenigen Sätzen formulierbar, was passieren soll.

Das hört sich super an, ist allerdings nie so einfach. Man kann ja nicht 
für jeden der 2^64 möglichen Eingangswerten der sin-Funktion testen, ob 
das Ergebnis stimmt.

von Medizintechnik (Gast)


Lesenswert?

Softwaretest ist eine Disziplin für sich und das Thema ist viel zu breit 
um es mit ein paar wie den oben genannten Plattitüden zu erschlagen 
(Testarten, Testlevel, Testziele, Teststrategien, ...), z.B.:

F. B. schrieb:
> Für jede Codeänderung müssen auch die Tests nachgezogen
> werden.

Tja damit hat man schon den ersten Smell aufgedeckt, wenn das der Fall. 
Klingt nach zu viel WhiteBox und zu wenig BlackBox Tests und/oder sich 
ständig ändernden Interfaces / Requirements.

Dann werden quasi Unittests gleich gesetzt mit Klassentests, siehe:

A. S. schrieb:
> Und je
> mehr man die Abhängigkeiten zerfasert, umso eher sind Kontrollfluss und
> Kontext futsch (hidden), geopfert einer Testbarkeit bedeutungsloser,
> sinnentstellter Partikel.

A. S. schrieb:
> In der Praxis ist es meist umgekehrt: Abgesehen von trivialen
> Mini-Funktionen gibt es einen umfangreichen Kontext (was äquivalent zu
> Ein- und Ausgaben ist) und einfache, aber viele Abhängigkeiten.

Klingt nach einer suboptimalen Architektur, wenn man ständig viele 
kleine Abhängigkeiten hat. Kopplung <-> Kohäsion; dagegen helfen 
Domänenmodellansätze, um die Software zu konzipieren.

Aber wenn ich hier manche Aussagen so lese, glaube ich, dass ich noch 
lange Arbeit haben werde :-)

von Christoph Z. (christophz)


Lesenswert?

F. B. schrieb:
> Es gibt nur wenige Ausnahmen, in
> denen Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle
> Testen sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur
> Backend programmiert und wegen fehlender UI keine manuellen Tests
> möglich sind.

Mein kompletter Beruf besteht aus "wenige Ausnahmen": Echtzeit Embedded 
Software und FPGA Entwicklung. Kein UI, manuelles testen ist Aufwändig, 
Error Injection im echten System unzulässig (wir wollen ja nicht jedes 
mal destruktive Tests machen...)

A. S. schrieb:
> In der Praxis ist es meist umgekehrt: Abgesehen von trivialen
> Mini-Funktionen gibt es einen umfangreichen Kontext (was äquivalent zu
> Ein- und Ausgaben ist) und einfache, aber viele Abhängigkeiten. Und je
> mehr man die Abhängigkeiten zerfasert, umso eher sind Kontrollfluss und
> Kontext futsch (hidden), geopfert einer Testbarkeit bedeutungsloser,
> sinnentstellter Partikel.

mh schrieb:
> Das hört sich super an, ist allerdings nie so einfach. Man kann ja nicht
> für jeden der 2^64 möglichen Eingangswerten der sin-Funktion testen, ob
> das Ergebnis stimmt.

Ich gebe euch beiden absolut recht. Es ist nicht einfach.

Ich bin da Pragmatisch, ob test-driven-development (TDD), 
defect-driven-development (DDD), pair-programming, formale methoden, 
agile, XP etc. sind alles Ideen/Methoden/Ansätze und ich nehme mir das 
heraus, das gerade zum Projekt, Technologie und Team passt.

F. B. schrieb:
> Von diesem ganzen Humbug,
> automatisierte Softwaretests würden Zeit sparen, will ich erst gar nicht
> anfangen. Für jede Codeänderung müssen auch die Tests nachgezogen
> werden. Also jedes Mal doppelte Arbeit.

Wenn es uns Entwicklern Zeit spart ist es optimal gelaufen. Wenn es 
unseren Kunden Zeit spart oder Schaden verhindert, dann ist der 
eigentliche Zweck vom Testen (automatisiert und manuell) erfüllt.

Generell geht es ja darum Software Entwicklung als Ingenieurhandwerk zu 
verstehen und zu betreiben.

von Medizintechnik (Gast)


Lesenswert?

Und zum Thema:
Wir setzen auch punktuell Pair Programming und auch andere Technik ein, 
immer wenn wir der Meinung sind, dass es sinnvoll ist.
Z.B. im Multiprozess / Multithreadumfeld und zugehörige Tests, 
verallgemeinert, bei nicht-trivialen Themen, die Auswirkungen auf 
mehrere Bereiche der Software haben können und sich Fehler nicht nur 
lokal innerhalb einer Komponente auswirken können.
Wieviel Aufmerksamkeit man dem Thema Test widmet hängt stark vom Umfeld 
der Software und des Wartungszyklus ab.
Um mal zwei Extreme herauszugreifen:
Mobile-App mit einer Gesamtlebensdauer von vllt. 1-2 Jahren, die von 
einem Entwickler erstellt wird, braucht kein so ausgefeiltes Testnetz, 
wie eine Software mit einer Lebensdauer von 15-20 Jahren im 
Medizinbereich an der ~200 Entwickler tagtäglich arbeiten, ...
Gut benamte / strukturierte Tests helfen allerdings sehr, sich in eine 
Fremdkomponente schneller einzuarbeiten und erspart unnötige Detaildoku, 
die sowieso sofort veraltet, da nicht gepflegt.

von A. S. (achs)


Lesenswert?

Medizintechnik schrieb:
> Softwaretest ist eine Disziplin für sich und das Thema ist viel zu breit
> um es mit ein paar wie den oben genannten Plattitüden zu erschlagen
> (Testarten, Testlevel, Testziele, Teststrategien, ...), z.B.:

Hier ging es aber nur um Tests als Allheilmittel.

P. P. schrieb:
> Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann
> jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code
> schreibt.

Die Code-Qualität eines Entwicklers wird sich nicht ändern, wenn er für 
jede Zeile Code 2 Zeilen Test selbst schreibt. (mit 1:2 als typischem 
Verhältnis).

von Medizintechnik (Gast)


Lesenswert?

A. S. schrieb:
> Hier ging es aber nur um Tests als Allheilmittel.

Naja komm sind wir ehrlich. Jeder der irgendeine Technik in Bezug auf 
Software als Allheilmittel anpreist, kann direkt unter "nicht ernst zu 
nehmen" eingetütet werden, oder nicht?

von Mladen G. (mgira)


Lesenswert?

TDD steht für "Test Driven Design", man schreibt genau soviel test code, 
damit dieser fehlschlägt und man genau so viel prod code schreibt damit 
der Test durchgeht, nicht mehr.

Damit kann man eben das Design des Codes minimal auslegen, eben nur das 
was man wirklich braucht.
Ist schon eine Umstellung wenn man gewöhnt ist sich zuerst die Lösung zu 
überlegen, das macht man bei TDD in kleinen Schritten und erst dann wenn 
man es braucht.
Bei TDD geht es eben nicht darum, alle möglichen Tests vorher zu haben, 
das ist eher "Test First" und hat andere Ziele.

Grundsätzlich müssen bei TDD nicht alle Tests whitebox tests sein, in 
der Praxis sind sie das aber weil man damit die schnellste Feedbackloop 
hat, es sollte ja innerhalb von einer Minute mehrere Iterationen möglich 
sein.

Das Ergebnis sollte der minimale Prod Code sein der die Anforderung 
erfüllt und dann auch testbar ist, nicht 100% Testabdeckung oder gar 
dass alle Fälle getestet wurden.

von Uwe D. (monkye)


Lesenswert?

A. S. schrieb:
> Medizintechnik schrieb:
>> Softwaretest ist eine Disziplin für sich und das Thema ist viel zu breit
>> um es mit ein paar wie den oben genannten Plattitüden zu erschlagen
>> (Testarten, Testlevel, Testziele, Teststrategien, ...), z.B.:
>
> Hier ging es aber nur um Tests als Allheilmittel.
Sondern? Pairprogramming?


> P. P. schrieb:
>> Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann
>> jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code
>> schreibt.
>
> Die Code-Qualität eines Entwicklers wird sich nicht ändern, wenn er für
> jede Zeile Code 2 Zeilen Test selbst schreibt. (mit 1:2 als typischem
> Verhältnis).

Auch erfahrene Entwickler machen bei vermeintlich simplen Anforderungen 
Fehler.

In komplexen Umgebungen mit mehr als >>100k Zeilen Code ist 
Programmieren ohne strukturierte Tests ein absolutes Tabu. Und 
schließlich gibt es mehr als den funktionalen Test des Entwicklers… 
(Prozesstest, Integrationstest, …)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.