Gibts bei euch Pairprogramming

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

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

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.

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.

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.

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

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

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?

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.

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.

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.

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.

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.

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.

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

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

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.

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 :/

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.

Generalkonsul schrieb:
> Gibts auch Gang Programming?

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

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.

Gute Zusammenarbeit generiert Mehrwert. Verstehen nur Sozialphobiker 
nicht.

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.

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.

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ß?

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ß.

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.

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.

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.

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

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.

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.

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.

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.

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.

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 ;-)

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.

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.

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.

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 :-)

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.

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).

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?