At both small companies I worked at, the real value was in the business relationships built up (suppliers etc). The code could be rewritten. It wouldn't be bug-compatible, but all the ideas and design were backed up in engineers' minds.
There are even advantages from a clean slate methodology; if there’s sufficient buy in from management.
Reason being: if you have done things before and bore the weight of architectural misgivings, you can clearly reproduce the software.
The biggest barrier to doing this normally is:
A) time pressure.
B) pressure to use existing log available tech
C) pressure to be cheap (which is manifested most often in A&B but is it’s own thing too).
This causes “large rewrites” to be rushed, subpar and lesser quality as the emphasis often isn’t on getting to feature parity.
Regardless, if google lost their code- entirely, we would probably have search by next week, auth in a fortnight, mail by next month and something approximating google cloud by the end of the year.
Because a lot of the really hard lessons have been learned, a reimplementation is just time.
I do. If, and only if, you build up the exact same thing. Once engineers band together for a rewrite that changes project architectural, conceptual, and engineering principles, then you're looking at a runaway deadline.
At both small companies I worked at, the real value was in the business relationships built up (suppliers etc). The code could be rewritten. It wouldn't be bug-compatible, but all the ideas and design were backed up in engineers' minds.