Tenets are set of guiding principles that align your decisions to what matters most, they serve as durable decision rules that resolve recurring trade-offs. Every team must have them clearly defined in order to succeed.
Software engineering decisions are not black and white, everything is a trade-off. Should we use; Postgres or Mongo, Java or Python, CDC based replication or client side, etc. All of these questions cannot be answered with a blanket statement and context is integral.
Without creating a set of clear tenets decisions will feel ungrounded and arbitrary, whereas with tenets reproducible decisions can be made.
How does one go about creating them for their team or product? Look at what your product does that is a magnitude better than its competitors or the reason your team exists. If your team is focused on cyber security at your company than your principles should focus on keeping the company safe, keeping up to date with the latest attack vectors and enabling yourselves to quickly identify and mitigate issues.
Let’s look at an example of a team building an SDK for a database.
Scenario 1, your team is building the SDK for a banks financial data. Financial data is core to the business and needs to be handled with upmost care, as such prioritizing safety over (Database) feature access is prudent. Your principles could be:
- Our SDK prevents incorrect usage of the Database that could lead to data loss, data integrity issues or data inconsistencies
- Our SDK is opinionated on how the Database is used to ensure the highest availability possible
- Our SDK abstracts away Database concepts in favor of product or company level concepts to speed up feature development
Scenario 2, your team is building the SDK for a cloud offering Database (AmazonDB, CosmosDB, BigTable).
- Our SDK has feature parity with our cloud offering
- Our SDK is available in any language, runtime, environment our clients may need
- Our SDK is a thin unopinionated wrapper allowing customers to do anything they desire
Now think about how new Database features would be treated by both teams.
What about when management demands a feature that doesn’t align with your teams core tenets? This happens, at the end of the day your team exists to support the business, either guardrails need to be baked into the new feature or your tenets are misaligned and need to be reviewed.
If a feature overrides a tenet then it’s important to bake into the project guardrails that allow the tenet to be added back in later or to prevent misuse. The guardrails can be as simple (and unorthodox) as purposefully picking an out of date tool to force a redesign later or guarding the feature to select power users with broad adoption gated.
Instead if it turns out the business needs your team to move in a new direction, then, great, work with your team to understand the new goals and retrospect on new tenets and what needs to change.
Tenets serve to add determinism and clarity to your teams decisions. Future developers will understand why a certain choice was made and empower them to make the right choices. Users will appreciate the consistent user journey.