In finance there are so many trade-offs that this approach is most sensible. At some point, I was trying to get a project going while working with a partner PM. He was a perfectionist programmer and literally obsessed over things like "we gong to have a script sending emails in this format" etc. Guess what, after about a year, as we went live we discovered that the idea was non-viable (for non-algorithmic reasons). This was something that we should have found out in the early stages, maybe even by trying to trade the strategy manually.Sadly, the other way of programming, top-down waterfall, leads to technical people only seeing one way of doing stuff, becoming blind to all the possibilities. So I actually prefer MVP and refactoring, delaying decisions over time until I see clear benefits. It's a less linear way of working, requires support and discipline, but can be worth it both in time and quality in the end. If it leads to early retirement of the project, all the better. Not all ideas are great.