That’s something that comes with experience. I have seen people over-engineer things and subsequently fail.
I didn't mention, but the bug is in an external open source API, not my code. I consciously try to avoid overengineering, but I also try to avoid depending on other people's code. It's a tension. So my choices are: 1. Do I spend a week and fix this? 2. Do I move on and spend a week finding another system?
True/False A. Is it something that otherwise fits your needs? B. Do you have the skills and the knowledge of the system to fix it without breaking anything else? C. Do you know off hand another system that will do what you need? If B is False, you know what to do If A and B are true and C is False, you know what to do If all are true, then it’s a question of how much effort you’ve already invested in the current setup vs replacing a component
All are true, but I don't think it's about effort invested (that's a sunk cost fallacy, COME ON MAN, WE'RE TRADERS AMIRITE), it's about what will compound better in the long run. I spend a week, fix it, and make billions, or spend a week, use someone else's thing and make billions. Either way I make billions but the first way, I have a lot more fun So alright, I'll spend a week. If I can't fix it, I'll use someone else's thing.
As long as you make your billions, you're alright. Don't settle for less though, or you're stuck with no healthcare, no police and no firestation of your own.
It is not really, though. Sunk cost assumes that time or money spent does not change your state as an economic agent and only adds material possessions. You don’t know what will work in the long run because you have never done this in the long run. However, there is certain value of expertise - if you spent a month integrating a component into a system, you have intimate knowledge of that component that you will have to re-acquire if you install something brand new.