1
 
 
Account
In your account you can view the status of your application, save incomplete applications and view current news and events
September 23, 2013

14 Friends of Pair Programming

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:

  1. When will the pair programming project be a success?
  2. What do I want?
  3. 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
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:

  1. Introduce naming conventions
  2. 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.
  3. Avoid dependencies between tests
  4. 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.
  5. Eliminate concurrency problems in tests
  6. 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.
  7. Add tests for equals(Object obj) and hashCode()
  8. 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.
  9. Pair programming with meaningful breaks interrupt
  10. 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
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é Stiller
    02.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 Steinacker
    05.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 Breetzmann
    20.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

  • […] 14 Friends of Pair Programming http://dev.otto.de/2013/09/23/14-friends-of-pair-programming/ […]

  • […] 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

We want to improve out content with your feedback.

How interesting is this blogpost?

We have received your feedback.

Allow cookies?

OTTO and three partners need your consent (click on "OK") for individual data uses in order to store and/or retrieve information on your device (IP address, user ID, browser information).
Data is used for personalized ads and content, ad and content measurement, and to gain insights about target groups and product development. More information on consent can be found here at any time. You can refuse your consent at any time by clicking on the link "refuse cookies".

Data uses

OTTO works with partners who also process data retrieved from your end device (tracking data) for their own purposes (e.g. profiling) / for the purposes of third parties. Against this background, not only the collection of tracking data, but also its further processing by these providers requires consent. The tracking data will only be collected when you click on the "OK" button in the banner on otto.de. The partners are the following companies:
Google Ireland Limited, Meta Platforms Ireland Limited, LinkedIn Ireland Unlimited Company
For more information on the data processing by these partners, please see the privacy policy at otto.de/jobs. The information can also be accessed via a link in the banner.