Programming/Design Docs/Tenets: Difference between revisions
Jump to navigation
Jump to search
| Line 9: | Line 9: | ||
# '''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 === | ||
Revision as of 10:18, 9 June 2021
WIP
Examples
Some of these are mutually exclusive; choose which one(s) align with your priorities.
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.
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 tech debt that we will have to address in the future.