Private World

If you want to isolate developers from the effects of changes, Then: allow developers to have private work spaces containing the entire build environment.

## Relationships

### To be applied before

* Incremental Integration, Named Stable Bases and Programming Episode are inputs for Private World.

*Contents of following sections belong to the original Organizational Patterns website[1] and have been divided into following parts: Context, Problem, Solution, Discussion.*

## Context

... an organization is creating Named Stable Bases, and developers can build against these versions, integrating their own code with the latest of other code (Incremental Integration).

## Problem

How can we balance the need for developers to use current revisions, based on periodic baselines, with the desire to avoid undue grief by having development dependencies change from underneath them?

It is important for developers to work with current versions of software subsystems to keep up with the latest enhancements, avoid running into already fixed bugs fixed elsewhere, and to avoid getting out of sync with interface changes.

Introducing new software into an environment while debugging may cause grief by introducing new behavior, and providing distractions because of the time spent resolving integration issues in some cases, code may no longer compile due to interface changes.

However, we must balance these needs: the need to keep up to date with the need of developers to maintain a stable environment for feature development/bug fixing.

Some organizations, to facilitate Incremental Integration, will have a shared baseline of code, libraries, etc. Unfortunately changing a code base, even in a different subsystem, can cause problems when there are interface changes, for example. You want to avoid hearing stories about developers leaving a problem at night to view it in the morning with a clear head, only to find that one’s test environment does not compile.

## Solution

**Provide a mechanism where developers can maintain a Private World development environment. In their Private World they can control the rate of integration. This allows them to avoid having an integration step interrupt work in progress. The environment should represent a snapshot of all the software being developed in a**
system, not just the code the developer is modifying. Try to ensure that the private development area is not used as a means of avoiding integration issues.

## Discussion

A starting point for the independent development area would be one of the Named Stable Bases which have been previously released. Developers then build their software and any related software that depends on their software. Alternatively, you can provide the ability to do a private system build from source code (and other artifacts).

While allowing developers the freedom to decide when to allow changes into their space you need to make sure that the developers update their code as often as possible to avoid integration surprises. So encourage developers to integrate their code frequently, perhaps by providing a mechanism for easily backing out of a difficult change.

Depending on details of implementation, one consequence of this pattern might be that project disk space requirements may grow quickly as N developers will have their own copies of the source code. But the costs of personnel almost always exceed the cost of an extra disk. A modification to this approach is that stable and distantly related subsystems can be used by reference, but one should be made aware of when changes are imminent. In this case the configuration management system should provide access to prior Named Stable Bases as well.

## References

1. ↑ http://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patlets.html