Jo Woodison Page 1 5/5/2003

Managing Software Reuse with Perforce

by Jo Woodison, Mandarin Consulting


1. Abstract

Software reuse is touted as one of the biggest benefits of object-oriented programming,
and indeed we have been reusing software libraries for decades. However, reuse
practices have mostly been ad hoc, and the potential benefits of software reuse are still
rarely realized. This paper will discuss how Perforce can help manage reusable software
components with Inter-File Branching and associated reporting commands. Also
explored are some of the elements of reuse-based software development methodologies
and best practices.

The most recent version of this paper is located at http://www.mandarinconsulting.com/doc/reuse.html
1. Introduction

Reuse can take many forms many items used or generated in software development
can be reused. While this paper will introduce some of these, the focus of the paper will
more generally address how any artifact that may be reused can be managed in
Perforce. As with all things, there are many solutions to the same problem, and this
paper serves not to illustrate all possible solutions, but to highlight some of the
functionality and flexibility that makes Perforce an ideal tool for managing reusable
artifacts.

1. What is Reuse?

Software reuse is the practice of developing systems of components of a reasonable
size and reusing them [McIlroy], then extending the idea of components beyond just
source code to requirements, analysis models, design and test documentation and
suites. All stages of the software development process are subject to reuse
[Jacobson].

Here we will focus on how to manage the sharing of these items, but will not go into
specific details on all areas of reuse. Essentially, we are interested in how to manage
files on disk, shared at some level between projects, products and/or development
groups.

1.1. Container Based SCM?

The term container based SCM has been coined in connection with a process for
managing component based development. While it is true that component based
development involves a less linear approach to systems development in that each
Jo Woodison Page 2 5/5/2003
component evolves independently of the others, essentially, the problem is still one
of managing files on disk. The simpler and more efficient means of managing files
on disk is the one with the greater versatility for handling the new complexity and
reducing that complexity to something more easily manageable.

4. Why Reuse?

It is not a myth. Reuse has been proven to offer many rewards. When we reuse code,
components and other artifacts, our goals are to:
Reduce time to market
Reduce the cost of developing the product
Improve the productivity of the development teams
Improve the predictability of the development process
Increase the quality and reliability of the product

When reuse is mentioned, we often think only of code reuse. This is perhaps one of the
lesser productive forms of reuse. That is not to say it is of little or no value, just that
there are rewards to be gained in considering inheritance, template, component,
framework, pattern and domain component reuse. Additional worthy candidates for
reuse are our previously created use cases, standards documents, models, procedures
and guidelines.

Reuse eventually saves us time and money, and will ultimately lead to a more stable and
reliable product.
5. Why not?

Despite of all the perceived benefits reuse offers, the practice has yet to be adopted as
widely as it might. It is on the increase: perhaps due in part to an increasing body of
reusable artifacts whether in-house or provided by third parties; perhaps due in part to
the greater awareness of the benefits and the need to gain a competitive advantage.

Achievement of reuse has proven elusive, the reasons for which are many:
Insufficient means to identify candidates for reuse in the development
process
Lack of available components to reuse
Lack of flexibility in available components
Lack of tools to assist with implementing a reuse strategy
The software development process does not encourage reuse:
o There is no stage where we question what has been done before and
whether it can be separated out and reused
o Roles are not well defined for architects, domain experts, reuse engineers
o Procedures of analysis, design, code, review, inspection, walkthrough all
fail to consider reuse
Systematic reuse is not established as a best practice
Lack of perspective: reuse requires a broader view than that of single project
or product
Lack of trust, the not invented here syndrome
Jo Woodison Page 3 5/5/2003
Fear of dependence on others or of own redundancy
Lack of capital funding, the return on which is not realized until artifacts are
reused and reduce the cost of later development
o Initial funding is required to develop systems that are strong enough to be
reused
o Initial funding is required to train staff in a third-party vendors systems.

Managing the design, code and components is only part of the reuse problem, and from
this, you may surmise a small, yet not insignificant, part.

6. What does Perforce Offer?

Perforce offers us a variety of features to organize our code, identify what components
are located where and to control the publication of components for others to reuse.

There are three main type of reuse discussed here. While there are more scenarios,
they will mostly fit into one of these three categories: informal reuse, black box reuse,
and managed reuse.

6.1. Depot Structure

When considering how to structure your depot to best accommodate your reuse
needs, it is advisable to ask some questions on how these artifacts will be used.

Who will use these artifacts?
Who will modify them?
Do modifications be need to be distributed to all users/consumers?
Immediately?
Do all modifications need to be available for others to use?

The answers to these questions helps determine the most appropriate approach to
take. A combination of these methods may be used within an organization to
accommodate varying requirements between different artifacts.

6.1.1. Informal Reuse

The informal approach is perhaps the most common, and something that has
been used for some time.

Let us suppose that Project A has implemented some functionality, feature 123.
Project B needs this functionality. Project B might simply copy the source code
files that implement this feature from Project A. Project A will not give any further
updates to Project B, and Project B will not give any of its modifications back to
Project A.

Jo Woodison Page 4 5/5/2003
This is perhaps the most common type of reuse. In Perforce this is easily
managed with Perforces Inter-File Branching

mechanism.

Very simply, in this scenario, integrate is used to branch the appropriate files
from Project A to Project B. Those familiar with Perforce will already appreciate
this intuitive and lightweight approach. Integrate performs a virtual or lazy copy
of the specified files to the new location, simply maintaining a reference to where
the files originated from. The files themselves will not be physically created in
the Project B area of the source code repository until they start to diverge from
where they were branched (aka integrated) from. While the intention is for no
further exchange of changes between the projects, the option remains open and
valid should it be required.


6.1.2. Black Box Reuse

In the black box instance, a number of projects rely on a given component,
comp456. No project will modify this component; it may even be provided by a
third party. The projects must use the latest version of the component.

Jo Woodison Page 5 5/5/2003

In this example, the component is held separately in its own area. Each project
that uses that component uses the client workspace view to map the shared
component into the appropriate location within the project in the client
workspace. If a more recent version of the component is added to the repository,
all client workspaces will pick up those changes when they next synchronize.


6.2. Managed Reuse

In the managed reuse case, a number of projects may rely on shared artifacts.
These artifacts may, at times, be refactored. Each project may or may not want
to receive updates to the components they use immediately they become
available or perhaps later. Projects may or may not want to contribute their own
changes to the shared body of resources.

Jo Woodison Page 6 5/5/2003
In this case, there is a separate area in the repository (within the same depot or
in its own depot), for storing shared code. Dependent projects branch the
artifacts they need into their projects. They may update their copies by
integrating again if newer versions of shared artifacts become available.

Jo Woodison Page 7 5/5/2003

If objects in the shared area need to be modified, they are branched to keep the
primary sharing area stable. Once amended, tested or otherwise approved, the
refactored artifacts are integrated back to the primary shared line and are then
available for the other codelines to integrate from.

If a project wishes to submit modifications to the shared line, it should ensure that
it has integrated the latest version of the shared into its line, make the changes,
ensure they successfully complete the appropriate test suites or that appropriate
approval is obtained, and then seek approval from the shared line owner.

With managed reuse, it is essential to have an owner for the shared area. This
owner must clearly define the policies for the shared lines and supervise and
approve all submissions to the primary shared line.


6.3. Reporting Commands

In the following, command line examples are used for ease of typing. All of these
actions can be perforce in the Windows GUI, p4win. Refer to the p4 to p4win Users
Guide at the Perforce Software web site (www.perforce.com) for the equivalent
actions.

Perforce offers many reporting commands and these can be put to good use to give
us useful information about our components.
Jo Woodison Page 8 5/5/2003

For example, to find out which version of a component is published to others, you
can use the following commands:

Informal and Managed reuse:
o p4 integrated to show which integrations have been submitted
o p4 filelog to show the history of the files, including integrations and merge
actions
o p4 integ n to show whether a more recent version of the shared code is
available

Black box reuse:
o p4 have to show the revisions of files in the client workspace
o p4 sync n to show whether a more recent version of the shared code is
available

Using the always maintained, reliable integration history in Perforce, we can use
these commands to find out what component is used where and how the
components are distributed.

We can branch (integrate) different components at different revisions into our project
code base and Perforce gives the inherent ability to identify the versions and
dependent projects or products.

We can choose to maintain a refactor or other internal branch and restrict access to
it by other projects until it is proven good enough to release. Perforce gives us the
ability to control exactly what components are published, and in conjunction with a
protections scheme, we can control who it is published to. We have the ability to
distribute components in a flexible way that is easy for teams to reuse them and write
their own code to join them together or add extra functionality. Perforce tracks and
allows us to integrate changes between different users and usages of components
as well as the latest original component release. We are able to insulate the
environments for different teams, products, or projects as we deem necessary and
appropriate.

7. Best Practices

1.1. Reuse

If reuse is not a practiced in your organization today, it should be adopted
systematically and incrementally. In an existing organization, current operations
must be maintained, yet practices need to be kept up-to-date in order for the
company and its products to remain competitive. The way to implement a reuse
strategy is to be mindful of and balance these two conflicting pressures.

There should be some means to measure the progress of reuse in the organization.
What percentage of a system is being reused? What are the size, complexity, and
Jo Woodison Page 9 5/5/2003
interfaces of the reusable components? What is the savings in development time
and cost.

Use some economic guidelines to set your expectations. Some published rules of
thumb are:
A component has to be used three to five times to recover its initial creation cost
and the ongoing support costs
It costs 1.5 to 3 times as much to create and support a reusable component as it
does to implement a one use only component
It costs a quarter as much to utilize a reusable component as it does to develop a
new one
It takes two to three product cycles or about three years before the benefits of
reuse are realized and cover the initial costs

It is all object-oriented technology! It might be, but that alone does not grant you
reuse. Keep in mind that it takes a specific reuse agenda, comprising of process and
organizational steps and support, to create a reuse program, not just a single
programming language or narrow methodology [Pittman].

1.2. Perforce

Best practices in Perforce are well documented in [Wingerd] High-Level Best
Practices in SCM. These do not really change when structuring for reuse. To
summarize some key points:

Give each codeline a policy
Give each codeline an owner
Have a mainline or parent codeline
Branch only when necessary
Branch when you need to dont copy instead of branch
Branch on purpose
Branch late
Integrate/merge often
Keep it simple

Perforce is a very versatile and flexible, yet strong SCM system. It allows all manner
of possibilities and depot structures. It is advisable to keep the structure as simple
as possible to meet your needs. While clever and tricky set-ups can be designed,
one should be cautious with regards to confusing users to the point where they do
the wrong thing or do not know how to work with the system, and be wary of creating
an environment or structure which is difficult to maintain.

2. Conclusion
Perforce is a very intuitive, flexible and strong SCM system. The simplicity yet versatility
of its branching mechanism are arguably second to none. It provides us with reliable
capabilities to put together any combination of artifacts and manipulate them in isolation
or to be shared with other teams.
Jo Woodison Page 10 5/5/2003

While tools will ultimately advance to support the evolution of our software development
practices, at this stage, it is not Perforce that prevents us from reusing software.
Leverage the benefits of the SCM system to help improve your productivity by sharing
code, components and other artifacts.
A. References

Jacobson I., Griss M., and Jonsson P. (1997) Software Reuse: Architecture, Process
and Organization for Business Success, ACM Press Books/Addison Wesley Longman

McIlroy D. (1969) Mass produced software components. 1968 NATO Conference on
Software Engineering

Pittman M. (1993) Lessons learned in managing object-oriented development. IEEE
Software

Wingerd L., Seiwald C. (1998) High-level best practices in software configuration
management. Perforce Software

The most recent version of this paper is located at http://www.mandarinconsulting.com/doc/reuse.html
About the Author

Jo Woodison (jo@mandarinconsulting.com) has been working in the computer industry
for sixteen years. Her experience includes roles in product development, consulting,
teaching and pre- and post-sales support. She has worked in many different
environments across many different platforms, architectures, databases and of course,
SCMs. Her SCM of choice is, naturally, Perforce. After working at Perforce Software (the
company), Jo continued training and consulting by becoming a Perforce Consulting
Partner and Certified Trainer. Originating from England but having spent most of the last
decade in the USA, Jo is happy to be back in the US after living in Australia for almost
two years.