Principles of package design

The Reuse-Release Equivalence Principle (REP)
The granule of reuse is the granule of release.

The Common-Reuse Principle (CRP)
The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

The Common-Closure Principle (CCP)
The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package and no other packages.

The Acyclic-Dependencies Principle (ADP)
Allow no cycles in the package-dependency graph.

The Stable-Dependencies Principle (SDP)
Depend in the direction of stability.

The Stable-Abstractions Principle (SAP)
A package should be as abstract as it is stable.

Robert C. Martin, "Principles of Package Design", in Agile Software Development: Principles, Patterns, and Practices, 253-268.

See also the pages about these principles in the WikiWikiWeb.

Higlights on Spotify's squads model

The PO is the "entrepreneur" or "product champion", focusing on delivering a great product, while the chapter lead is the "professor" or "competency leader", focusing on technical excellence.

There is a healthy tension between these roles, as the entrepreneur tends to want to speed up and cut corners, while the professor tends to want to slow down and build things properly. Both aspects are needed, that's why it is a "healthy" tension.

[...]

Technically, anyone is allowed to edit any system. Since the squads are effectively feature teams, they normally need to update multiple systems to get a new feature into production.

The risk with this model is that the architecture of a system gets messed up if nobody focuses on the integrity of the system as a whole.

To mitigate this risk, we have a role called "System Owner". All systems have a system owner, or a pair of system owners (we encourage pairing). For operationally critical systems, the System Owner is a Dev-Ops pair – that is, one person with a developer perspective and one person with an operations perspective.

The system owner is the "go to" person(s) for any technical or architectural issues related to that system. He is a coordinator and guides people who code in that system to ensure that they don't stumble over each other. He focuses on things like quality, documentation, technical debt, stability, scalability, and release process.

The System Owner is not a bottleneck or ivory tower architect. He does not personally have to make all decisions, or write all code, or do all releases. He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership. However, from time to time he will take a "system owner day" and do housekeeping work on that system. Normally we try to keep this system ownership to less than a tenth of a person's time, but it varies a lot between systems of course.

We also have a chief architect role, a person who coordinates work on high-level architectural issues that cut across multiple systems. He reviews development of new systems to make sure they avoid common mistakes, and that they are aligned with our architectural vision. The feedback is always just suggestions and input - the decision for the final design of the system still lies with the squad building it.

Henrik Kniberg & Anders Ivarsson, in Scaling Agile @ Spotify, 12-13.