Minimising Points of FailureMay 13th, 2019
When it is right, it is right. Code behaves as intended when implemented correctly. One of the best courses to get closest to right as fast as possible is to minimise the points of failure.
By focusing on reducing the number of things that can go wrong, you will inherently reduce how much testing is required, how difficult it is to maintain, and develop more rapidly.
One such example is creating and updating objects. You want enough flexibility that these two processes can go their separate ways if need be, but upon going their separate ways, it creates more things to test.
By getting the create/update code in the same spot, you can reuse all of the validation, all of the SQL queries, all of the language for form elements etc.
Depending on how you do it, a single SQL query can handle adding and updating elements. I like to you REPLACE INTO for simplicity, however this can be dangerous with foreign key constraints that coalesce. You can also do INSERT INTO ON DUPLICATE KEY UPDATE. I respect that decision as it does well to get things in one spot and doesn’t run the same risk with foreign key constraints. The queries are bigger though.
Fell free to send me benefits to minimising points of failure.
jsturgis May 13th, 2019ABOUT THE AUTHOR:
Please excuse my lack of attention to spell checking and grammar. I was probably busy thinking about better variable names. I am a Model 3 owner and lover and TSLA long only ever looking to increase position as the exponential growth in TSLA revenue will inevitably dominate the failing FUD. Sending a dumb tweet is easy. Building a Gigafactory are not. (See what I mean about the grammar?) Place your bets accordingly.