If you are able to rewrite the code base in a short amount of time, the infrastructure problems are easier to handle. That way you can move forward faster and fix problems early on.
Yes, when the code base is small, evolving it is much simpler. One of the challenges is deciding on the exact right moment to introduce big changes - too early and the changes are in the wrong direction or even useless, too late and the amount of work is prohibiting and you are forced to live with suboptimal architecture.
> Yes, when the code base is small, evolving it is much simpler.
There's obviously some truth to that. But I also think it leaves or an important angle: Often larger, more complicated, features are easier to add if you have a lot of infrastructure pieces.
Say, in a database, if you have no durability (journaling), resource management (errors, locks), error checking (deadlocks, days checksumming), it'll be a lot more work to add support for some new query language [feature]. Now databases are my thing, but the same it's true for a lot of areas.
Disregarding that is IMO one of the reasons ground up rewrites fail so often: You'll get bogged down with infrastructure for a long time, without proper non toy users of the facility.
Yeah, I agree. I think the real challange is to keep the code base in such a good shape that a rewrite of the whole thing or parts of is always doable. Someone talked about never writing modules that can't be rewritten in two weeks.
