I generally lend towards in place refactoring.
The cases where a rewrite might be better.
- The code is really bad to the point of being broken.
- The code is incomplete with no significant amount completed
- The code is really, really bad, not just spaghetti but serious architecture issues that affect the ability to refactor in place as well as the correctness (i.e. works but buggy). Case in mind, new table created everytime a user joins the site and the code relies on that table being in existence.
Refactoring
- The site is live with users
- The codebase is siginificant
- The codebase is more or less working
Most sites are going to fall under the second set and so to just scrap it would be a waste of resources. It may seem like a great idea to just start everything over, but really it's a significant time investment, time that you aren't working on new features as well. And it is often the case that there is more to the code than your realized/remembered, so the refactor takes longer than you thought too.
Refactoring allows you to work towards this better code base without starting over, so you can allows have the live site without having to manage two different ones. And you don't have to finish it all to see improvement. Working on pet profile? Okay refactor that when you make your change.
This is the route I went for Animal Acres and I think it's been working out pretty well. There are some quirks to the code now having different paradigms ongoing, but there are so many features and sometimes even ones I don't realize about until I get into the code (was a purchase initially). Had I went the other route, I would still be working on it and new features would have been hard in that time. I'd either have to not have realized them or code them in the old poor style and in the recoded version. Instead I just code it one way which can then be released right away on the new site.
It's not quite as nice as working on Eliyo, but it's really not bad either. Was able to pull in eloquent and blade, so much of it is