Software design principles for teams: The Principle of Singular Authorship.

Aspire to make every codebase look like it has been written by a single expert developer. You will fail dismally at this, but that shouldn’t stop you trying.

Background

This is an elaboration of one of the principles I originally published in the following article…

Software design in teams: principles for technical leaders

Principle

Aspire to make every codebase look like it has been written by a single expert developer. You will fail dismally at this, but that shouldn’t stop you trying.

---

Firstly, why a single expert developer?

Simply put, a single developer implies a highly cohesive, singular approach to design. A single expert developer implies that approach to design will result in high quality code.

However the ebbs and flows of team composition mean that many developers of varying levels of capability and attitude will be contributing to your codebase over time… Ay, there’s the rub¹

Every change to your codebase beyond “Initial Commit” increases the inevitable crawl towards code entropy. Each new developer brings their own experience and preferences towards the code they write. Even the passage of time changes the approach to design of individual developers as their own experience evolves. An even more aspirational version of this principle could be “… has been written by a single expert developer in a single session”.

As a technical leader, how you approach this principle with the forces of project physics mentioned above is critical. As usual, there is a spectrum of attitudes where either extremes are unhelpful. At one extreme, you can police the codebase as sole gatekeeper to all changes, ensuring your brain is the only filter through which all changes must pass. At the other end of the spectrum, you throw your hands in the air, give in to the anarchy and let the codebase evolve in a completely ungoverned manner.

The healthy approach between these extremes is to act as a guiding force patiently and gently nudging the evolving codebase back towards a singular vision. This can be done in a number of different ways:

• Asking developers working on new features whether this problem has been solved elsewhere in the codebase, and how. Note: the best time to ask these questions is when new feature work is being started, not when the feature is being reviewed after completion.

• Communicating frequently about the emergent approaches to design. This is especially important when onboarding new team members. If this communication is written, it should be easily discoverable from the codebase (e.g., in a README.md).

• Ensuring sufficient automated checking to design is in place to provide tighter, faster feedback loops around the approach to design. See also Principle #2.

• Clearly establish and communicate limits around experiments with different approaches to design, a la “we’re going to spent the next iteration building the new Registration feature as a purely stateless service. We’ll assess whether this approach is more broadly applicable when the iteration is complete.” See also Principle #6.

1. Hamlet, Act 3, Scene 1