An Example of Using Rod's Pattern DTD

Here's an example of a pattern marked up using the pattern document type defintion. Following the markup are some examples of renderings that might be generated from the XML code.

You can return to the main page for Rod's draft pattern DTD.

(My apologies to Jim Coplien and AT&T, they have nothing to do with this. I simply needed a short, concrete and easy to follow example. The original version of this pattern can be found at http://www.bell-labs.com/people/cope/Patterns/Process/section18.html.)

<!--
################################################################################
# EXAMPLE OF PATTERN MARKED-UP USING PATTERN.DTD TAGS                          #
################################################################################
-->
<!-- header and reference to dtd ommitted -->
<pattern>
  <name>Code Ownership</name>
  <problem>
    <thumbnail>
      A Developer cannot keep up with a constantly changing base of
      implementation code.
    </thumbnail>
    A Developer cannot keep up with a constantly changing base of
    implementation code.
 </problem>

 <context>
   <thumbnail>
      A system with mechanisms to document and enforce the software
      architecture, and developers to write the code.
   </thumbnail>
   A system with mechanisms to document and enforce the software
   architecture, and developers to write the code.
 </context>

 <forces>
   <itemlist>
     <item>
       Something that's everybody's responsibility is no one's
       responsibility.
     </item>
     <item>
       You want parallelism between developers, so multiple
       people can be coding concurrently.
     </item>
     <item>
       Most design knowledge lives in the code; navigating
       unfamiliar code to explore design issues takes time.
     </item>
     <item>
       Provisional changes never work.
     </item>
     <item>
       Not everyone can know everything all the time.
     </item>
  </forces>

  <solution>
    <thumbnail>
      Each code module in the system is owned by a single Developer
      who is the only only allowed to modify the module.
    </thumbnail>
    Each code module in the system is owned by a single Developer.
    Except in exceptional and explicit circumstances,
    code may be modified only by its owner.
  </solution>

  <resultingContext>
      The architecture and organization will better reflect each
      other.
  </resultingContext>

  <relatedPatterns>
    <!-- Note that by "before pattern", I mean that the referenced
         pattern establishes the context of this one.
         By "after pattern", I mean that this pattern helps to
         establish the context of the referenced pattern.
      -->
    Related patterns include
    <patref pattern="Architect Also Implements"
            relation="before pattern">Architect Also Implements</patref>,
    <patref pattern="Organization Follows Market"
            relation="before pattern">Organization Follows Market</patref>,
    and
    <patref pattern="Interrupts Unjam Blocking"
            relation="after pattern">Interrupts Unjam Blocking</patref>,
    <P>
    The pattern
    <patref pattern="Review The Architecture"
            relation="after pattern">Review the Architecture</patref>
    helps keep designers and architects from developing tunnel
    vision from strict application of this pattern.
  </relatedPatterns>

  <rationale>
    Lack of code ownership is a major contributor to discovery
    effort in large-scale software development today. Note that
    this goes hand-in-hand with architecture: to have ownership,
    there must be interfaces. This is a form of
    <!-- Note that by "example of", I mean that this pattern is
         an example of the referenced pattern.
      -->
    <patref pattern="ConwaysLaw"
            relation="example of">Conway's-law</patref>-in-the-small
    (see also
    <patref pattern="Architect Also Implements"
            relation="before pattern">Architect Also Implements</patref>).
    <p>
    Arguments against code ownership have been many, but
    empirical trends uphold its value. Typical concerns include
    the tendency toward tunnel vision, the implied risk of
    having only a single individual who understands a given piece
    of code in-depth, and breakdown of global knowledge. Other
    patterns temper these problems (see
    <patref pattern="Review The Architecture"
            relation="after pattern">Review the Architecture</patref>
    and <patref pattern="Engage Customers">Engage Customers</patref>.
    <p>
    Tim Born argues that there is a relationship between code
    ownership and encapsulation, in the sense that C++ protection
    keeps one person from accessing the implementation of
    another's abstraction.
    <p>
    Law is property, and the lack of identifiable property leads
    to anarchy (Rousseau et al.).
    <p>
    It has been argued that code ownership should be applied only
    to reusable code. Such a constraint would be worthy of
    consideration if someone comes up with a good distinction
    between usable code and reusable code.
  </rationale>

  <version>
    <date>1995.03.23</date>
    <time>09:00:44 CST</time>
    <revision>1.0</revision>
  </version>

  <copyright>Copyright &copy; 1995 AT&T</copyright>

  <author>
    <propername>
      <firstname>James</firstname>
      <lastname>Coplien</lastname>
    </propername>
    <email to="cope@belllabs.com"
           subject="Code Ownership">cope@belllabs.com</email>
    <href url="http://www.bell-labs.com/people/cope/index.html">
      http://www.bell-labs.com/people/cope/index.html</href>
    <org>
      <name>AT&T Bell Laboratories</name>
      <href url="http://www.att.com/index.html">
        http://www.att.com/index.html</href>
    </org>
  </author>
</pattern>

<!--
################################################################################
# END EXAMPLE                                                                  #
################################################################################
-->

Here's one rendering that might be generated from the mark-up. Note that the order of the sections here is diffenent from that of the XML source.

Code Ownership

James Coplien <cope@belllabs.com>
AT&T Bell Laboratories <www.att.com>


Rev. 23 March 1995; Copyright © 1995 AT&T

context

    A system with mechanisms to document and enforce the software architecture, and developers to write the code.

problem

    A Developer cannot keep up with a constantly changing base of implementation code.

forces

    • Something that's everybody's responsibility is no one's responsibility.
    • You want parallelism between developers, so multiple people can be coding concurrently.
    • Most design knowledge lives in the code; navigating unfamiliar code to explore design issues takes time.
    • Provisional changes never work.
    • Not everyone can know everything all the time.

solution

    Each code module in the system is owned by a single Developer. Except in exceptional and explicit circumstances, code may be modified only by its owner.

consequences

    The architecture and organization will better reflect each other.

rationale

    Lack of code ownership is a major contributor to discovery effort in large-scale software development today. Note that this goes hand-in-hand with architecture: to have ownership, there must be interfaces. This is a form of Conway's-law-in-the-small (see also Architect Also Implements).

    Arguments against code ownership have been many, but empirical trends uphold its value. Typical concerns include the tendency toward tunnel vision, the implied risk of having only a single individual who understands a given piece of code in-depth, and breakdown of global knowledge. Other patterns temper these problems (see Review the Architecture and Engage Customers.

    Tim Born argues that there is a relationship between code ownership and encapsulation, in the sense that C++ protection keeps one person from accessing the implementation of another's abstraction.

    Law is property, and the lack of identifiable property leads to anarchy (Rousseau et al.).

    It has been argued that code ownership should be applied only to reusable code. Such a constraint would be worthy of consideration if someone comes up with a good distinction between usable code and reusable code.

related patterns

    Related patterns include Architect Also Implements, Organization Follows Market, and Interrupts Unjam Blocking,

    The pattern Review the Architecture helps keep designers and architects from developing tunnel vision from strict application of this pattern.

Here's a "thumbnail sketch" generated from the XML source. This could be listed, for example, as an "external patterns" section of a pattern that references this one.

Pattern Name Problem(s) Addressed Proposed Solution
Code Ownership A Developer cannot keep up with a constantly changing base of implementation code. Each code module in the system is owned by a single Developer who is the only only allowed to modify the module.

(Again, my apologies to Jim Coplien and AT&T, they have nothing to do with this. I simply needed a short, concrete and easy to follow example. The original version of this pattern can be found at http://www.bell-labs.com/people/cope/Patterns/Process/section18.html.)