Until it does matter. Then it *really* matters at which point you're normally looking at a bottom up rewrite and likely retooling and rehiring for new skills.
Ive been bitten by "oh it's just a prototype" a few too many times now.
It's a prototype because when you start a project :
- you don't understand what the client wants
- the client themselves don't really understand what they need (and sometimes, not even what they want, which is magnified as soon as you have to deal with multiple people)
- you might not know how to achieve that
- you might have an idea how to achieve that, but not have practical experience in it
- reality (including funding limitations) restricts what solutions can be implemented
- the usual code entropy...
Given all of the above, why would you NOT do a bottom up rewrite at least once ?!
P.S.: And in the cases the performance critical bits can be isolated, Python can outsource those to performant languages like FORTRAN or C.
I am guessing the answer usually is : the funding doesn't come directly from the end user, and so the incentives are not aligned for a successful project - which also explains why software projects have such poor success rates (~10%) ?
A pattern I’ve frequently seen is schedule pressure mounts and when you need to scale back on scope to meet a deadline, rewrites are the first to go.
I’d guess a good portion of the garbage people inherit from others fits into this category.
It might not be aesthetically pleasant but it works.
If we think about it, most of the time you do not need to do that because some library author has already done it.
If one needs to write the native code it is not overengineering. It is only overengineering if it was not needed in the first place.