I'd say "you gotta do what you gotta do, but don't be lazy": 1. think before you do something. i.e. architect towards known knowns. 2. refactor when new infor

I'd say "you gotta do what you gotta do, but don't be lazy": 1. think before you do something. i.e. architect towards known knowns. 2. refactor when new information becomes available. Most people have a problem with 1 and just go blindly into random search, with the thought: "we can just try this; we can always refactor later" That is fine if you cannot predict the outcome. However, if you never try to become good at predicting outcomes you will get stuck in "lets try" mode. If you practice predicting outcomes i.e. architecture code/product ( 'think without actual coding'), you will find that more often it guides the way to the highspeed lane and allowing you skip a couple of "iterations/sacrifices" ( but obviously not all... )