The first two of the above principles (STWP and CHIP) are derived from the Single Responsibility Principle (SRP). Here's how:
The Single-Threaded Workspace Principle (STWP)
A private workspace should be used for one and only one development change/task at a time. The STWP is basically a statement about multi-tasking. It says that a worker in a dedicated workspace should work on only one thing at a time within that space. This is done to avoid the overhead, complexity, and interruption of flow that results from frequent context-switching between multiple tasks.
The Change Identification Principle (CHIP)
A development change should clearly correspond to an intended development task (e.g., for a fix, feature, or enhancement). The CHIP is basically saying that development changes should be transparent to the extent that they are intention-revealing. A change is transparent if its container is visible and can be readily used to reveal its contents. Also, its container or content should clearly identify the corresponding task behind performing the change. This might be accomplished by associating the change with a record in a tracking system, such as a feature, fix, or enhancement.
Last month, we concluded that the OCP translated to the concept of preserving the identity or essence of its container. What does it mean to preserve the essence of a change? Preserving the essence of change means that if we say a change is in the codeline, we have a way of knowing and showing that its in there, both functionally and physically. We must have a way of detecting and identifying its presence, content, and behavior.
The Change Auditability Principle (CHAP)
A change should be made visible within its resulting configuration. The CHAP goes a step further than the CHIP. The CHIP simply says that a change needs to reveal its intent. The CHAP says a change needs to prove its existence in form, fit, and function. CHIP is a promise that the change is authorized and planned, while CHAP verifies that the promise was fulfilled. Taken together, the CHIP and CHAP are about establishing trustworthy transparency for a change/task. We do this by being able to repeatedly and reproducibly demonstrate and report the request, status, and results of a change, as well as the "who+what+when+where" of a change. The former is often stored and managed in the tracking system and the latter is typically captured within the version-control repository when the changes are checked-out and in.
The principles of package cohesion (REP, CRP, and CCP) all seem to point to the notion of a change as a single, atomic unit.