> "Anytime an engineer tells me that the only solution to something is to "bite the bullet and rewrite everything," I lose all respect for them"
Pretty closed minded approach. Just because it is usually not a good idea to do a rewrite, does not mean it is always true.
Here is an example which indicates you are probably wrong with that type of thinking:
What happens if a shop decides to store all their data in flat text files initially because it was easier and they were not expecting it to scale much. Later on and after huge expansion they realize that flat text files really is not the best solution, in fact it is pretty much the worst solution and decide that a rewrite with better technology is needed.
At this point you say you lose all respect for them? Does that attitude make sense?
There's a huge difference between "our web site slow, so let's throw it out and rewrite the whole thing" and "our web site is slow. after profiling it seems our main bottleneck is the procedure that writes to these text file. I did a quick proof of concept where I replaced the text files with postgresql and I got a 2500% speed up. I'd like to try to implement this on our production site and see if it solves our performance problems".
I have two problems with someone saying that the "only solution" is to "rewrite everything."
Being an engineer myself, I know how easy it is to see things as black and white and that the right answer is "just so obvious." But the more I do, the more I see that this approach is almost always wrong or, at best, half-baked.
In most situations, there is more than one option. So, to say that rewriting everything is the only solution, especially when the guy doesn't even work at Facebook, is a classic example of engineering arrogance.
The second problem I have with the original comment is that it doesn't acknowledge that, in any situation, tradeoffs exist. The way you sell things, both to executives and potential customers, is not to just come in and say "there is only one right answer, you have to do it this way" but to provide a thorough analysis of the current situation, acknowledge the different tradeoffs and provide options based on the top few scenarios.
Then it seems likely you're either correct and working with very poor engineers or making very poor and potentially incorrect assumptions based on your own lack of understanding of the code. I've been brought on to several projects over the years that simply could not move forward due to totally unsalvageable development failures; that's definitely not the case in every instance, but it absolutely does happen.
"Everything" in the context of the quote only refers (as far as I can tell) to code that accesses the database and it does not imply that the entirety of facebook needs to be transitioned simultaneously. It's a far cry from the naive "we'll rewrite the app and everything will be better" mentality that you seem to be referring to.
Pretty closed minded approach. Just because it is usually not a good idea to do a rewrite, does not mean it is always true.
Here is an example which indicates you are probably wrong with that type of thinking:
What happens if a shop decides to store all their data in flat text files initially because it was easier and they were not expecting it to scale much. Later on and after huge expansion they realize that flat text files really is not the best solution, in fact it is pretty much the worst solution and decide that a rewrite with better technology is needed.
At this point you say you lose all respect for them? Does that attitude make sense?