Wednesday, April 11, 2012

Pair Design

A lot of times, when writing software, a pair programming approach is used. It's an agile software development technique in which two programmers work together at one workstation. At any time, one is the "driver" and the other "navigator", and the roles are switched at intervals. Basically the "driver" is writing the code, and the "navigator" is simultaneously reviewing the code in progress.

I got introduced to this approach during my undergraduate, and we had to use this approach whenever we were working on an assignment in groups of two. Pivotal labs seems to be using pair programming approach quite effectively. I am not sure which other companies use this approach, but it seems the pair programming idea can be extended to the design process as well.

Generally an engineer (let's call this engineer the primary engineer) gets a task, maybe fixing a bug, improving a feature, or building a new API, all of which involves thinking and designing a solution. The primary engineer designs the solution, and the paired engineer is there to discuss the solution, address any limitations, good parts, and improvements before coding commences. The paired engineer will be a sounding board for the primary engineer to think aloud about the proposed solution. Of course, the roles will be reciprocating.

I am not saying don't evaluate designs as a team, this is very valuable, and is usually reserved for something significant. But for day to day design of solutions, having an assigned sounding board can help the primary engineer to think aloud about the problem. Each paired design partners will rotate, maybe every sprint, for example. This way, each team member will also get a chance to work with others, and an informal review process for designs will naturally set in.

Just a thought.

No comments:

Post a Comment