[arkitaip]

Complete rewrites are considered bad because over time code accumulates implementations of below-surface knowledge that often gets overlooked and can take a lot of time to re-discover. Edge cases, debugging voodoo, pony requests - there are lots of reasons why this happens. Pseudocode example: if users A,C,P try to submit report x on dates y1...y3 make sure to remind them of policy change z. Because this type of code often is very chaotically codified in the physical world - your German intern, who documented his code in English and German and passed away last summer in a freak glockenspiel accident, rest his soul, received a bunch of bug reports through email, the old bugtracker and fax from your European customers - it may be very easy to miss during the requirements gathering phase of your rewrite.

On the other hand, if you're about to become as big as Twitter and Facebook wrt managing users, data, latency and traffic, you'll have to do all kinds of performance optimizations throughout your entire tech stack. This might involve rewriting your code because your code is based on fundamentally flawed design decisions (hey, non-concurrent code seem like an fine idea when you started out with your batch processing but pretty soon you'll need to time travel if those nightly cronjobs are to be finished in time) or too cthulhulian to mantain anymore. But then again, 99.99999% of all sites simply don't consistently experience performance issues on the same level as Twitter or Facebook, so that's another reason why you should focus on agility and delivering value instead of performance (unless, of course, performance truly is a key feature) initially in a software project.

[jdelsman]

I think developers should be conscious of the underlying performance issues/workarounds of their platforms and technologies and implement those early. There is nothing worse than wasting capital early just because you have to throw servers at something once you hit exponential growth.