3 ms·
Building a new system inside an old one assumes that you have something to work with. Sometimes the new system needs to be so different from the old one that t
by YZF 13y ago
Building a new system inside an old one assumes that you have something to work with. Sometimes the new system needs to be so different from the old one that this is impossible. If you think about this as a multi-dimensional optimization/search problem when you do the incremental approach you are holding N coefficients constant while modifying some other (usually <<N). If your target system is completely different (==architecture) you'll never get to it with an incremental refactoring effort.
For those who haven't read this one I think it's pretty good:
http://programmers.stackexchange.com/questions/6268/when-is-a-big-rewrite-the-answer http://programmers.stackexchange.com/questions/6268/when-is-...
- InclinedPlane 13y agoTrue, and hopefully nobody took my 2 examples as the only methods or suitable conditions for a rewrite. A rewrite is risk, a huge amount of risk. And often taking on risk can be bad, but often taking on risk is married to the possibility of huge wins. It takes good judgment and solid development practices to take on risky projects and persevere, but it can be done, and indeed is done all the time. Going into a rewrite nonchalantly with a thousand casually made false assumptions and all the while squeezing your dev. and QA cycles between two products is a very, very common way to waste a lot of effort and seriously hurt your company, especially in the market. So be aware of what you're taking on when you take on a rewrite. As a general rule if your team/company is capable of taking on and succeeding at tasks that others typically struggle at then that can be a key competitive advantage.