[ukoki]

This reminds me of my experience as a senior contractor joining teams that seem to enjoy endless discussion. For example, when implementing a new feature using an open-source library or framework they will want to make a prototype of all possible libraries, make a report about each of them, have some big discussions about which to choose, and only _then_ start the real implementation. My advice is always to just pick the one your gut tells you is the right one -- if the prototype works, then that _is_ the implementation and we can stop considering alternatives unless we have a good reason to reconsider them.

If a decision is hard to make, its often because the differences are small, and therefore it doesn't matter much and you might as well decide by dice-roll.

[Ma8ee]

> If a decision is hard to make, its often because the differences are small, and therefore it doesn't matter much and you might as well decide by dice-roll.

My life became soo much easier when I had that insight. I used to spend so much mental energy on decisions that most often were inconsequential.

[Ferret7446]

I'd like to know where you're getting these decisions. All of my hard decisions are due to not knowing what technical obstacles we'll run into later.

[Ma8ee]

That is often a different type of difficulties. I was thinking about decision like, should I buy car A or car B. I've done my research. Economy, safety, et c. are very similar. But it is a lot of money, and I don't know which is the "best", and of course I want the "best". I could spend weeks on a decision like this. Now I just acknowledge that they seem to be equal. Car B comes in a nice shade of red that I really like, so I buy car B.

Regarding your question, there's always going to be known and unknown unknowns down the line. My only advice in that case is to get to the unknowns as fast as possible. And from the start take into account that you most likely will have to rebuild a big part when you learn more. That is one of the reasons modularity and decoupling is so important. You want to be able to easily scrap and replace one part without it affecting everything. And keep it simple. Never try to build something that should be capable to handle all imaginable scenarios in the future. You'll be bitten by one of the unimaginable ones, and your complex "can handle everything" architecture will be too rigid to change.

[hinkley]

I don't know what the black art of tool selection is, but I'm at least a couple std deviations above average on picking libraries that have legs. Nobody gets it right every time, but some people seem to get it wrong every time.

Be sure the work is given to someone who puts some intention into tool selection and you'll probably be okay though. We don't need three different tools doing the same kind of tasks. But sometimes the old old stuff gets moved to the new tool because the old tool couldn't handle that scenario.