Of course, it still happens all the time. But that is a challenge to (carfully!) correct the poor modularisation and get rid of the fence.

I don’t mean that as a defense of PHP, just as an example of what you can mange to do if you sink enough costs.

I have developed a bias toward refactoring applications in place, rather than rewriting them. I have found that programmers love the idea of rewriting as a default position, but that their (our! optimism masks the true enormity of effort required. As a business proposition, a rewrite is much more costly. For example who will actually *do* the rewrite, and who will train them? Will they be new employees, or existing ones? If new, who will train them? If existing, who maintains the existing application? Indeed, what is to be done with the existing application while the rewrite takes place?

So while it may be true that a ground-up rewrite every couple of years reduces maintenance headaches, I assert it will be at the cost of increasing business-as-a-whole headaches. “There are no solutions, only tradeoffs” etc.

Again, in the interest of full disclosure, I have a book and an online course about refactoring applications, so my bias may be coloring my opinion. It is a hard-won bias, for good or ill.

Also, for larger teams, you are never doing the rewrite with the same team, so it’s easy to overestimate how much better you will do the next time. The mostly new team understands some of what the software does, but is also unfamiliar with a lot.

If we were discussing politics, I would refer you to Chesterton’s Fence (http://www.chesterton.org/taking-a-fence-down/). That’s the intersection I find interesting: is that the same mental pattern, or not? Is it more appropriate in one case than the other, and why?

Eek. Granting for the sake of argument that all software applications need to be rewritten periodically, I think some of them would need the period pushed out to considerably more years than that, in some cases to more than a decade. Look at a reasonably capable renderer like povray, luxrender, or mitsuba. Or, for better-known examples, look at various optimizing compilers, or TeX, or emacs. Many of them are showing their age, and might well have benefited from rewrites every 5-15 years, but I don’t think it’s really feasible to rewrite them every 2 years, and I doubt it would be helpful.

Your rewrite from scratch position is in the foundational document of software process: The 1970 Royce paper that defines the waterfall software process suggests that the ONLY way to do a waterfall project well is to do the full requirements, analysis, design, code, etc. approach, then throw away the result, and start over now that you have enough information to do something intelligent.

This is the single largest overlooked claim in software.

My data point:

At [large software company where I work], we’re rewriting/migrating stuff all the time; the joke is that every service is either deprecated or not-yet-ready.

http://joelonsoftware.com/articles/fog0000000069.html