Category Archives: DS

Agile, DS, Scrum, XP

Notes on Pair Programming

Leave a comment

I can’t remember exactly when the Pair Programming bug started biting around Design Studio, but a first glimpse was given by Dan Cromer and (I think) Kevin Mehlbrech during my senior year. It was just another exercise for class, it seems, but for whichever reason – propaganda or awareness – it caught on this year in a form.

But pair programming as it has been done in Design Studio makes me nervous.

Observations

  1. Pairs are often established for an iteration timeframe.
  2. Pairs are often established between a person of high expertise and a person of low expertise.
  3. Pairs do not switch roles on a regular basis.
  4. Pairs tend to switch among (graph-wise) cliques within the team.
  5. Pair programming is sometimes used when it is unnecessary for the task.
  6. Pair programming roles are not followed.

My Interpretation

  1. Iteration Pairing: This can work, and if iterations are short, may be the way to go.
  2. Expertise Disparity: This, I believe, is generally highly detrimental to learning on behalf of both parties and reduces the output of the team.
    • Two expert people will push each other to a higher level.
    • Two novice people will learn at a pace that is suited to them – they will avoid having terms thrown around that go over their head and the inevitable “just let me do it” moments that kill learning and morale.
    • Disparity can work if the expert acknowledges their teaching role – that is, they must be patient and stick strictly to the pair role they have at any given time.
  3. Not Switching: Buy 33 of these timers – 3 for each team – no pair will be without one. The switching interval really depends on what is being worked on, but something between 20 minutes to an hour is within reason. Providing some Command Adhesive strips to attach the timers to monitors temporarily would also help visibility and remembering to use the tool.
    4. Clique - the sociographical kind!
  4. Cliques: This might be helpful in some circumstances. The cliques that form aren’t necessarily the social kind – it seems they form around interest in a particular aspect of the project or a specific technology. The risk here is not having other members of the team involved with an area of the project, which I think is mitigated by having two team members with detailed knowledge of the area. (They may not ride in the same car.)
  5. Unnecessary: Some tasks simply don’t require pair programming. If the technology is familiar and everyone understands what you are doing – a “time suck” type of task – then don’t waste a resource to sit there and nod.
  6. Roles: Pair programming defines two roles: Driver and Navigator. These roles are exactly analogous to the roles in rallying: The driver controls the machine (in detail); the navigator (or co-driver, as they prefer and are acknowledged to be called) knows the overarching plan and assists the driver with the necessary instructions.

Epic Digression: Driver and Co-Driver

Guarantee these two people are in-sync.

Rallying is a form of motor sport using stock or near-stock street cars. The courses traverse public roads, gravel roads, dirt roads, snow, and desert. Unlike other motor sport, the routes are generally not circuitous – that is, they do not perform laps of the same course in continuous succession. Instead, it is a timed race from point A to point B – stages can be up to 20 miles long. Obviously, they’re moving quite fast, and generally, they have only driven the route a few times before. For that reason, the driver depends on the clear, concise, and precise pace notes of the co-driver. When you’re moving 150 miles per hour, it’s very important to be in sync. The co-driver watches the road to match with his recorded notes and adjusts his timing to the conditions. The driver, then, is focused completely on how to get the car through the described path as fast as possible. The driver is concerned with the implementation details of that path: gear changes, steering input, avoiding obstacles, adjusting to different surfaces.

Pacenotes are concise, precise, and might be adjusted in real time.

This just-in-time approach of both implementation and direction is, it seems, at the core of pair programming as well. An important note: the co-driver generally writes pace notes ahead of the event. Analogously, the pair programming co-driver should have an over-arching plan (perhaps a story) with some details (perhaps tasks) in place before starting. The details can then be adjusted on-the-fly by the driver.

Agile, DS, Scrum, technical, XP

TDD: the war on errors

2 Comments

In the past two years, there has been an emphasis on Test Driven Development in Design Studio.

There seems to be a misconception about the past, though: it’s sometimes spoken as if testing was not part of DS previously. This is untrue – no team fired up notepad, wrote some code, and turned it over. Instead, “testing” has come to mean “having a robust automated test suite.” That’s great, and it is amazing that so many more teams are building those suites now. But we also have to remember it isn’t the only part of how we should test software.

Below is my first draft of a process-style diagram of how things “should be” in our process. It’s far too big to fit in here at 100% size, so click through to see it in all its glory. I’m looking for any thoughts or corrections to it before I make a final infographic-style rendition.

A few things to note:

  • The axes. Horizontally, the client-team responsibility levels: The further an item is to the right, the less directly the client is involved. Vertically, the “language spectrum”: The further towards the bottom, the simpler it usually is to verify a typical statement in the language involved. I will have to enumerate the various levels later, but “Vision” would be at the top and most project-specific, and something like machine code at the bottom being least project-specific.

    Let me know what you think!