For me the best analogy is a carpenter tightening screws. When you start out solving a particular problem part of the scope and required functionality is always

For me the best analogy is a carpenter tightening screws. When you start out solving a particular problem part of the scope and required functionality is always not 100% clear. So you start out with an implementation which favors flexibility over things such as DRY or performant. As you learn more about the problem you start to optimize. One of the biggest mistakes (the biggest one is probably not writing tests) I see junior engineers make is trying to optimize before fully understanding the required functionality.