Informations
Jobs
What is pair programming?
In pair programming you sit with a pair (usually 2) programmers at one computer and work on the same code. And that is supposed to make sense? ... We programmers in the Shopoffice team think so: Yes! We write better code, produce less bugs, are more concentrated at work and most important: We have more fun at work.
Sure, we already use pair programming extensively here in the team - but there is always something to improve. So why not bring someone into the team who has more practice in this area and has had experience with pairing in various projects? We decided to bring in Thomas Much to join us for a sprint. Thomas had already been on numerous projects as a Java and Pair Programming coach and that's exactly what we wanted to benefit from.
Every team member here surely had their own idea how Thomas could integrate into the team to make us better pair programmers. That's why, at the beginning of the coaching, we put our ideas together and thought about how the collaboration could work. Each team member had the opportunity to say:
- When will the pair programming project be a success?
- What do I want?
- What do I not want?
We came to the conclusion that Thomas should not exclusively pay attention to our pairing behavior. Rather, he should pay attention to everything he notices in our daily work - i.e. Scrum methodology, programming methodology and potential "broken windows" in the code.
We then started the Sprint. Thomas then "paired" through the team each day, learning about our way of working and the overall system. At the beginning of each day, we pragmatically decided in the Daily which pairs would work together on a task. After just one day, Thomas was able to get his bearings and start giving us tips and making suggestions for improvement.
pair-programming-bei-otto2
As discussed in the kick-off, we took time in the middle of the sprint for coach feedback. Some suggestions for improvement were included in a presentation. Fortunately, the feedback was largely positive. Our pairing behavior, the test-driven work, the code design were praised. But also many small things, for which we have simply become too operationally blind, were to be found here as suggestions for improvement:
- Introduce naming conventions Class, method and variable names are not always clearly and consistently named in the project. For example, superclasses are sometimes prefixed with Abstract and sometimes with Base. A method for loading an entity sometimes starts with get, load or find. Consistent and uniform naming and thus a uniform language throughout the project helps with understanding.
- Avoid dependencies between tests Kent Beck describes that good tests are: 1. isolated, 2. automated, 3. quick to write, 4. quick to run and 5. unique. Dependencies between tests should therefore be avoided. Isolated from other tests, each unit test should only test exactly one aspect.
- Eliminate concurrency problems in tests Here again, one can rely on Kent Beck 's advice. As long as each test works in isolation, all tests can be executed in parallel. Thus, no shared, non-thread-safe resources may be used in the tests.
- Add tests for equals(Object obj) and hashCode() When overwriting equals(Object obj ) and hashCode(), people often forget to pay attention to the overwritten methods when refitting the class. Tests help to uncover these errors.
- Pair programming with meaningful breaks interrupt Pair programming is often felt as more strenuous and more energy-consuming than independent programming. To keep concentration high throughout the day, there is a recommendation to take smaller breaks more frequently throughout the day.
The coaching ended together with the end of the sprint. This also gave us a good topic for the retrospective to evaluate the coaching. What did it do for us as a team? What did it do for me personally.
Here are the core statements of the results:
- Good notes on architecture and programming methodology.
- Better tests
- Increased code quality
- unfortunately too little about pairing
- beer (!)
In the end, the coaching did not bring us an enormous profit, but what remains is a good feeling that we are on the right track. Many tips were helpful and will help us to become even better and more effective in the upcoming sprints. We also started to implement the tips right away. Alright, triples might be ineffective. But according to the motto "A lot helps a lot!" we are now programming in sextuple.
pair-programming-bei-otto3
8Comments
- 04.10.2013 09:15 Clock
Hi José, schön, dass dir der Artikel gefällt. Wegen deines Vorschlags: Schick mir doch einfach eine kurze Mail, dann schauen wir, was wir hinbekommen!
- José Stiller02.10.2013 16:17 Clock
Super Sache! Man sollte hier vielleicht auch einfach mal erwähnen, dass Pair Programming zwar schon lange an Universitäten gelehrt werden aber bei weitem noch nicht die Verbreitung in Unternehmen finden, wie es eigentlich sein sollte.
Während des lesens des Artikels kam mir gerade eine Idee. Diese ist vielleicht zu hoch gegriffen oder Absurd aber darf man auch als Mitarbeiter im Zuge des PP mal für ein Tag bei euch mitmachen. Klar meine Aufgaben sind hier im Unternehmen eigentlich andere, aber man würde so vielleicht auch einfach die Leute sowie und vor allem die Arbeit kennen lernen. In wie fern ich da nun ein Vorteile draus ziehen kann, weiß ich gerade nicht. Aber ich finde den Gedanken sehr interessant. - Guido Steinacker05.10.2013 12:52 Clock
Hallo José,
in unserem Team (Entdecken aka FT3) hatten wir gelegentlich schon mal einen Interessenten, der für einen Tag mit uns zusammen im Pair gearbeitet hat. Wir können gerne über Stefan oder mich einen Tag vereinbaren.
VG, Guido - Robert Breetzmann20.02.2014 20:48 Clock
Hallo Dirk,
vielen Dank für deinen Kommentar. Beim Pairen versuchen wir, wie bei allen anderen Dingen übrigens auch, gesunden Menschenverstand walten zu lassen. Es gibt also keinen Zwang dazu. Beim Daily wird meist entschieden, welche Paare zusammen an den Tasks arbeiten. Dabei versuchen wir immer neue Kombinationen zu finden. Um herauszubekommen ob Konstellationen zu häufig vorkommen, hilft eine Pairing-Matrix in der man festhält, wer mit wem gepaired hat.
Wenn es sich einrichten lässt, dann pairen wir den ganzen Tag, unabhängig davon ob jemand eingearbeitet werden muss oder das Thema neu ist. Somit ist niemand allein für den Code verantwortlich (Stichwort: Collective Code Ownership). Coding-Conventions haben wir, sind aber nicht mehr so wichtig. Es entsteht schnell ein gemeinsames Verständnis von gutem Code. Das Team lernt somit viel voneinander und das ist gut für die Qualität!
Viele Grüße,
Robert Breetzmann - 19.02.2014 12:15 Clock
Interessanter Beitrag.
Wir bei aixigo (www.aixigo.de) sind mittlerweile auch vermehrt mit Pairprogramming unterwegs. Nach meinem eigenen Erfahrungen ändert sich die Arbeitsweise aber ziemlich stark und einige Dinge fallen irgendwie unter den Tisch, wenn man den ganzen Tag "paired".
Wie macht ihr das? "Paired" ihr den ganzen Tag oder nur stundenweise?
Das ganze Projekt durch, oder nur am Anfang bis jeder im Thema und mit den Entwicklungswerkzeugen firm ist?
Wann wechselt ihr eure Paringpartner?
Welche Erfahrungen habt ihr mit der Codeverantwortung gemacht? Wenn jeder alles macht, kann man sich ja ganz gut in der Gruppe verstecken. ;-)
Coding-Conventions machen sicherlich auch Sinn oder kann bei Euch jeder nach eigenem Gutdünken kodieren.
Gruß,
Dirk - 18.12.2015 14:55 Clock
[…] 14 Friends of Pair Programming http://dev.otto.de/2013/09/23/14-friends-of-pair-programming/ […]
- 29.05.2017 17:18 Clock
[…] collections. Immutability as default is a milestone in my life as a developer. I compare it to git, pair-programming, continuous integration and IntelliJ IDEA (with Cursive now, of course). There was a time when I […]
- 02.11.2018 12:39 Clock
[…] des kurzen Zeitraums waren wir, dank zahlreicher Entwicklerbeteiligung, in der Lage zum Teil Pair Programming einzusetzen. Dabei viel auf, dass zwar auch zwei übermüdete Entwickler vor einem Rechner teils […]
Write a comment
Answer to: Reply directly to the topic
Written by
Robert Breetzmann
Similar Articles
Katharina MariaJune 26, 2024Why technical writers can rescue us
03Find out how technical writers make complex software understandable and accessible and create standards and centralized knowledge!DevelopmentOperationsWorking methods
NinaApril 17, 2024Meet Nina – From Healthcare Management to Software Development
02Find out how Nina mastered her career change into software development with the help of her team and her great enthusiasm for IT!DevelopmentOperationsWorking methods
