Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

One Size Fits None


One Size Fits None

The IT community operates on a fundamental assumption of software development "best practices," demanding that we use them on all projects. For example, model reviews, detailed requirements documents, change control boards (CCBs) and pair programming are typically referred to as best practices. But reality reveals that one size does not fit all: I believe that these are actually contextual practices that work in some situations, but not others—there's really no such thing as "best practices." To be truly effective developers, we must know a wide range of development techniques, and, equally important, understand the context in which to apply them.

Consider code inspections: A group of your peers, perhaps in a facilitated meeting, reviews your code and provides feedback. According to Capers Jones (Software Assessments, Benchmarks and Practices, Addison-Wesley, 2000), Tom Gilb (Software Inspection, Addison-Wesley, 1994) and other experts, code inspections are effective in identifying potential source code problems that span deviations from accepted coding practices to incorrectly implemented requirements.

Now consider pair programming: working with another programmer at a single keyboard. Its proponents insist that this approach results in higher-quality code, greater understanding of the system's design, and enhanced skill transfer among team members. Pair programming works particularly well when you swap pairs on a regular basis, use a common and agreed-upon set of coding conventions, and have a shared code base throughout the team.

To Each Its Own

Code inspections and pair programming are widely considered best practices that should be globally adopted. Unfortunately, reality isn't this simple. Code inspections are effective in environments where collaboration between programmers is minimal and people "own" their own sections of the code. When collaboration is low, programmers have little opportunity to share improvement ideas and techniques, allowing deviations in their work over time. Worse yet, when people work alone on code for long periods of time, they can unwittingly introduce defects that go undetected. In these situations, holding code inspections is clearly a good idea because it forces other "pairs of eyes" to examine your code. But what if you have the benefit of a highly collaborative, flexible work environment? In that situation, code inspections may not be just superfluous; they can actually impair the development process.

Because of the high degree of collaboration it engenders, pair programming works best in trusting and respectful environments. When you pair program, you must stay focused on actually writing code because you know your partner is sitting beside you. If you deviate from the coding conventions, forget to write a unit test first or get stuck on syntax, your partner can take the helm. But if your environment isn't supportive of highly collaborative work, pair programming may prove an abysmal failure.

Two Great Tastes

Should we use these two "best practices" together? Perhaps—but in my experience, in an effective pair-programming environment, the value of code inspections plummets. Why don't these two practices fit together? First, the contexts in which each is effective are worlds apart. Second, as you can see in "Pair Programming vs. Code Inspections," the two techniques overlap significantly, each thereby reducing the other's unique value.

But is one practice a replacement for the other? Not really. Although the two techniques share several benefits, each approach is best suited for different situations. Although pair programming delivers more benefits than code inspection, it does nothing to convince people external to your team that you're doing a good job. Similarly, code inspections are no replacement for pair programming because they don't produce working software.

Compare Baskets, Not Fruit

Ultimately, however, weighing details of the two techniques makes as much sense as comparing apples and oranges. What does make sense, but is clearly much harder to achieve, is to compare collections of practices—baskets of fruit, if you will. For example, you could weigh a set of agile practices against a set of traditional practices. The agile basket might hold pair programming, collective ownership, test-driven development (TDD) and refactoring. The traditional basket might contain code inspections, model reviews, up-front detailed design and unit testing. Each basket holds a group of synergistic practices that covers a comparable set of issues, enabling a fair comparison. Better yet, because each collection of practices is commonly bundled together within its respective development community, the relative effectiveness of agile and traditional software development can potentially be determined.

The process and organizational patterns community had it right all along: You must first understand a problem's forces (its context) to apply a solution that adequately addresses them. Having done so, a new situation arises that requires a different pattern. To succeed, you need a collection of patterns, called a pattern language. Jim Coplien's work in this area (see www.bell-labs.com/user/cope/Patterns/Process/), specifically his architecture process patterns, is the best-known example of process pattern languages. Replace the terms pattern with practice, force with issue and pattern language with collection of practices, and we're talking about the same basic concepts.

Farewell, Fantasyland

Just as you use the right tool for the job, you must apply the right development practice for your situation. This requires the skills to identify the situation you currently face, proficiency in a wide range of practices, and an understanding of the context in which each practice works.

In software development, "best practices" inhabit a sort of fantasyland, where waving a magic process will solve all your problems. Reality, however, demands specific attention to specific issues. Customizing your practices to fit the problem will get you much farther on the road to success than flailing about with an all-purpose—and ineffective—magic wand.

 

Pair Programming vs. Code Inspections

Pair Programming

  • Validates code in progress
  • Builds trust internally within the team
  • Produces working software
  • Promotes consistent coding style
  • Clarifies design ideas in detail
  • Educates people in new development skills
  • Provides opportunities to apply new development skills in progress
  • Holds team members personally accountable to one another
  • Keeps team members on task

Code Inspection

  • Validates code after the fact
  • Builds outsiders' trust in the team
  • Produces an assessment record
  • Promotes consistent coding style
  • Communicates detailed design to date
  • Educates people in new development skills
  • Holds the team accountable to external people
  • Verifies progress to date



Senior Contributing Editor Scott W. Ambler is author of the Productivity Award-winning Agile Database Techniques (Wiley, 2003).


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.