Software design in teams: principles for technical leaders
A set of principles for technical leaders struggling with establishing conventions around software design within their team.
Engineering teams should spend time regularly talking about software design. Teams are a social construct performing a socio-technical activity and the approaches to design they adopt form part of the informal social contract they share.
How to navigate the rocky road of these discussions can be a source of much frustration to technical leaders, experienced or otherwise. Too much time spent on this activity can be frustrating for everyone, especially if the team finds itself relitigating previous decisions. Alternatively, spending too little time could be the signs of a team that does not care sufficiently about the quality of the code they write, nor about how it forms part of a larger codebase.
The following principles are the ones I use1.
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. [Singular Authorship]
Automated style checking is your friend. Maximise this within reason. [Appropriate Automation]
Code is read far more than it is written: “clever code” ages like seafood in the sun. [No WTFs]
Design decision making - like modern life - is not a democracy. The technical leader’s vote counts for more. Use this power wisely. [Benevolent Dictator]
Design decision making is also not an aristocracy, where only highly opinionated and loudly spoken people are represented. These people will leave your team one day… what then? [Inclusivity of Opinions]
Open your codebase to new approaches to design… in a controlled, contained and collaborative manner. [Intentional Experimentation]
If you use code reviews to gate merging, support review feedback that does not block merging. [Non-blocking Review Feedback]
Establish an idiomatic bar for your tech stack. This bar should not trip people over (be too low), nor require a step ladder (be too high). [Idiomatic Low Bar]
Consider design norms outside your team at your leisure. Ignore them at your peril. [Aligned Autonomy]
A word of warning: These principles may make this process simpler, but they will never make it simple. Tradeoffs are everywhere in your role and no set of principles consider your specific context to make the tradeoffs appropriately.
Or attempt to use whenever possible.