Programming/Design Docs/Tenets: Difference between revisions
Jump to navigation
Jump to search
(Created page with "{{Note|WIP|warn}} == Examples == Some of these are mutually exclusive; choose which one(s) align with your priorities. === Long Term Decisions === # '''Make It Work''': We...") |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Note| | == What is a tenet? == | ||
{{Note| a principle, belief, or doctrine generally held to be true, especially one held in common by members of an organization, movement, or profession|info}} | |||
Tenets are used as guidelines when making design decisions. In software, there is no "right" solution to a given problem statement, but there is never enough time to build everything. It's important to determine what tech debt is considered acceptable. There will be disagreements on design choices, but consensus will be easier to achieve if you've already decided what to prioritize. If your team or organization can agree on a set of tenets, this will help guide your design and shorten the review process. | |||
== Examples == | == Examples == | ||
Some of these are mutually exclusive; choose which one(s) align with your priorities. | Some of these are mutually exclusive; choose which one(s) align with your priorities, or write your own (catchy summary titles optional). | ||
=== Long Term Decisions === | === Long Term Decisions === | ||
| Line 9: | Line 13: | ||
# '''Make It Work''': We focus on completing the MVP (minimum viable product) in the given timeframe. While we don't want to make decisions that will hinder scalability, it is not our initial priority. | # '''Make It Work''': We focus on completing the MVP (minimum viable product) in the given timeframe. While we don't want to make decisions that will hinder scalability, it is not our initial priority. | ||
# '''Space Odyssey 2000''': We will be starting out making this product a monolith to reduce devops and sysops overhead. We understand that this may create tech debt in the future if we decide later on to make micro-services. | # '''Space Odyssey 2000''': We will be starting out making this product a monolith to reduce devops and sysops overhead. We understand that this may create tech debt in the future if we decide later on to make micro-services. | ||
# '''Micro-Services''': We are willing to take on the overhead of a micro-service architecture in order to avoid the headache of managing a monolith. | # '''Micro-Services''': We are willing to take on the initial overhead of a micro-service architecture in order to avoid the future headache of managing a monolith. | ||
=== Technology === | === Technology === | ||
# '''Brave New World''': We are willing to try out new technology for this product. We understand that while we are learning these new technologies, we will make mistakes and spend more time researching than developing, but we are willing to invest this time to try something new. | # '''Brave New World''': We are willing to try out new technology for this product. We understand that while we are learning these new technologies, we will make mistakes and spend more time researching than developing, but we are willing to invest this time to try something new. | ||
# '''Stay the Course''': While new technology is enticing, this product should use languages and technology already known by developers; we do not want to spend a lot of ramp-up | # '''Stay the Course''': While new technology is enticing, this product should use languages and technology already known by developers; we do not want to spend a lot of ramp-up time learning how to build and maintain this product. | ||
=== Easy of Use === | === Easy of Use === | ||
# '''Make It Easy''': We focus on making it easy to add data. We understand this may compromise data integrity, but it is more important that users have fewer barriers to adding data. | # '''Make It Easy''': We focus on making it easy to add data. We understand this may compromise data integrity, but it is more important that users have fewer barriers to adding data. | ||
# '''Make It Right''': We focus on data integrity. We understand this may require more time to build in the necessary input validation, but it is imperative that the data is correct. | |||
=== Testing === | === Testing === | ||
| Line 25: | Line 30: | ||
# '''Fool Me Once...''': When a bug occurs, we fix the issue for good. We invest the time in analyzing the root cause and in adding validation to stop similar issues earlier in the pipeline. | # '''Fool Me Once...''': When a bug occurs, we fix the issue for good. We invest the time in analyzing the root cause and in adding validation to stop similar issues earlier in the pipeline. | ||
# '''Less Can Be More''': Each test validates a specific functionality. Changing one behavior should result in only updating one or a few tests. | # '''Less Can Be More''': Each test validates a specific functionality. Changing one behavior should result in only updating one or a few tests. | ||
# '''Risky Business''': We have high risk tolerance and choose to prioritize getting the product out over automated testing. We acknowledge this will result in tech debt that we will have to address in the future. | # '''Risky Business''': We have high risk tolerance and choose to prioritize getting the product out over automated testing. We acknowledge this will result in test-writing tech debt that we will have to address in the future. | ||
{{Design Docs}} | |||
Latest revision as of 17:59, 14 July 2021
What is a tenet?
a principle, belief, or doctrine generally held to be true, especially one held in common by members of an organization, movement, or profession
Tenets are used as guidelines when making design decisions. In software, there is no "right" solution to a given problem statement, but there is never enough time to build everything. It's important to determine what tech debt is considered acceptable. There will be disagreements on design choices, but consensus will be easier to achieve if you've already decided what to prioritize. If your team or organization can agree on a set of tenets, this will help guide your design and shorten the review process.
Examples
Some of these are mutually exclusive; choose which one(s) align with your priorities, or write your own (catchy summary titles optional).
Long Term Decisions
- Make It Work: We focus on completing the MVP (minimum viable product) in the given timeframe. While we don't want to make decisions that will hinder scalability, it is not our initial priority.
- Space Odyssey 2000: We will be starting out making this product a monolith to reduce devops and sysops overhead. We understand that this may create tech debt in the future if we decide later on to make micro-services.
- Micro-Services: We are willing to take on the initial overhead of a micro-service architecture in order to avoid the future headache of managing a monolith.
Technology
- Brave New World: We are willing to try out new technology for this product. We understand that while we are learning these new technologies, we will make mistakes and spend more time researching than developing, but we are willing to invest this time to try something new.
- Stay the Course: While new technology is enticing, this product should use languages and technology already known by developers; we do not want to spend a lot of ramp-up time learning how to build and maintain this product.
Easy of Use
- Make It Easy: We focus on making it easy to add data. We understand this may compromise data integrity, but it is more important that users have fewer barriers to adding data.
- Make It Right: We focus on data integrity. We understand this may require more time to build in the necessary input validation, but it is imperative that the data is correct.
Testing
- The Earlier The Better: We catch potential issues as soon as possible, preferring to place validation as early as possible in the pipeline.
- Fool Me Once...: When a bug occurs, we fix the issue for good. We invest the time in analyzing the root cause and in adding validation to stop similar issues earlier in the pipeline.
- Less Can Be More: Each test validates a specific functionality. Changing one behavior should result in only updating one or a few tests.
- Risky Business: We have high risk tolerance and choose to prioritize getting the product out over automated testing. We acknowledge this will result in test-writing tech debt that we will have to address in the future.