You can definitely go the other way to overthink a problem, even as high to induce the halting problem. Absolute optimization is mathematically impossible, and an imperfect choice has to be made at some point.

Measure once, cut twice, earn one to throw away.

This is a bad analogy for software. One of the unique properties of software, compared to other crafts, is that the material cost of iteration is virtually zero. We should use that to our advantage instead of pretending we're carpenters.

Often fixing fucked up shit takes more time than doing it from scratch but because of the system has been built around the fucked up shit you can't just throw it away and then you end up having to deal with continuously paying the higher than should price.

In software the material cost is not the cost of a concrete material such as wood (like you mentioned) but developer time

Even using the carpentry analogy, I suspect the point is to avoid ruining something on which a lot of time was spent. The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly.

The other thing to bear in mind is that there is always more work to be done than time to do it. You have to factor in opportunity cost. As many other commenters have said, ultimately it's a balance which depends on your company's particular situation.

> The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly.

Thanks to version-control software it's also incredibly cheap to experiment freely with an existing code-base in a completely non-destructive fashion. I see no reason to treat existing code as fragile or precious.

Sounds nice on paper. Reality is, you figure things as you go along. Plan for 6 months, and you will see you have 6 months of work.... Get to action first, and you'll have maube 6, maybe 7... Anyways...

Not ideal, but mistakes and experiments seem to be the best way people learn.

There's nothing wrong with making mistakes in experiments. However, when you're building financial systems, there's absolutely no room for mistakes.

Most financial systems are designed to have room for mistakes.

Banks keep ledgers of transactions instead of just the balances, so that if an account balance is off, it can be recalculated from the transactions.

Transactions can be cancelled in case there was an error.

Invoices are often checked by humans before they are sent to customers, introducing an option to catch errors. If the customer receives a faulty invoice, they can contact whoever wrote it and ask for a correction. And so on.

Of course, there isn't room for error in every corner -- having a flaw in an authentication or authorization protocol could be very costly to recover from.

But in general, the assumption that in finance in general, there is no room for mistakes is simply false.

There is always room for mistakes if you start by building prototypes. In fact having first approximation prototypes allows one to catch mistakes in how systems and subsystems interact early and fix those at a fraction of the cost.

Developing on a live fintech system is a different kettle of fish

> However, when you're building financial systems, there's absolutely no room for mistakes

Then I can assume that all of your financial software has verification proofs and/or is fully model checked? If not, then clearly there is room for mistakes even in finance.