some necessary refactorings, such as, a change in a widely used API, you may have no choice but to dive into tens or possibly hundreds of files. You’ll want this to happen as quickly as possible so you’ll automate the refactoring. With a consistent style, you can probably do this fairly easily. If you have to account for the many ways you can do things in Perl, you’ll probably resort to hand editing each file. Not only is this labor intensive, but it’s error prone, too.

Even when you aren’t making global changes, you and your partner still have to read unfamiliar code. A programming pair’s ability to read and to communicate through the code is affected directly by its consistency. Communication is hard enough without you and your partner having to wade through several code dialects. And, allowing for style variations when writing code opens up too many unnecessary thoughts. Do I adapt to my partner’s style? Should we adopt the style of the code we’re editing now? Or perhaps, I should insist on my style. After all, it has worked well for me over the years. Starting out with an agreed upon style, frees our minds of such distractions and allows us to focus on the important bit: solving the customer’s problem.

9.3 Team Colors

In Extreme Programming Explained, Kent Beck wrote, “The standard must be adopted voluntarily by the whole team.” This may not be so simple. Establishing consensus requires work on everybody’s part. If your team has coded together before, you’ll probably have an easy time agreeing on a style.

For newly formed teams, use the style guide as a team building exercise. Everyone should be encouraged to contribute. If a particular point is too contentious, drop it until after the first iteration or so. The goal is to get full consensus on the entire guide. If someone is particularly inflexible during the discussions, it’s a warning sign that a team adjustment may be necessary. Better sooner than later.

A style guide can be highly motivating, however. It’s like your team’s colors. It’s something relatively insignificant which provides significant cohesion. If even one team member is coerced into agreement, the team isn’t sticking together, and the rift may grow into a chasm. When everybody voluntarily accepts the style choices, you are functioning as a team, and you are ready to code.



	some necessary refactorings, such as, a change in a widely used API, you may have no choice but to dive into tens or possibly hundreds of files. You’ll want this to happen as quickly as possible so you’ll automate the refactoring. With a consistent style, you can probably do this fairly easily. If you have to account for the many ways you can do things in Perl, you’ll probably resort to hand editing each file. Not only is this labor intensive, but it’s error prone, too. Even when you aren’t making global changes, you and your partner still have to read unfamiliar code. A programming pair’s ability to read and to communicate through the code is affected directly by its consistency. Communication is hard enough without you and your partner having to wade through several code dialects. And, allowing for style variations when writing code opens up too many unnecessary thoughts. Do I adapt to my partner’s style? Should we adopt the style of the code we’re editing now? Or perhaps, I should insist on my style. After all, it has worked well for me over the years. Starting out with an agreed upon style, frees our minds of such distractions and allows us to focus on the important bit: solving the customer’s problem.

	9.3 Team Colors In Extreme Programming Explained, Kent Beck wrote, “The standard must be adopted voluntarily by the whole team.” This may not be so simple. Establishing consensus requires work on everybody’s part. If your team has coded together before, you’ll probably have an easy time agreeing on a style. For newly formed teams, use the style guide as a team building exercise. Everyone should be encouraged to contribute. If a particular point is too contentious, drop it until after the first iteration or so. The goal is to get full consensus on the entire guide. If someone is particularly inflexible during the discussions, it’s a warning sign that a team adjustment may be necessary. Better sooner than later. A style guide can be highly motivating, however. It’s like your team’s colors. It’s something relatively insignificant which provides significant cohesion. If even one team member is coerced into agreement, the team isn’t sticking together, and the rift may grow into a chasm. When everybody voluntarily accepts the style choices, you are functioning as a team, and you are ready to code. Copyright © 2004 Robert Nagler 69 All rights reserved nagler@extremeperl.org