3 ms·

Its not like I had to shut off the old site while I worked on the new codebase... The old codebase was running perfectly fine, up until I shut it off and replac

Its not like I had to shut off the old site while I worked on the new codebase... The old codebase was running perfectly fine, up until I shut it off and replaced it with the new code.

aidos 13y ago
There are plenty of projects where by the time you've finished your rewrite the product will have moved on so far that you'll have to rewrite some again. I seem to recall Facebook making several attempts to rewrite in a language other than php but the codebase just evolved too quickly.
- etler 13y ago
  You don't rewrite for features. You rewrite for better maintainability and productivity. After your rewrite you shouldn't have to rewrite it again. The balancing act is that a rewrite should improve your implementation velocity, so while it may be a setback, your velocity should be much higher than your competitors, so over time you would be able to surpass them and then gain a lead they cannot beat thanks to your higher productivity. As the technical debt grows, your productivity will get slower and slower, so you won't be able to keep up with your competitors anyways. That's the gamble. Just because Facebook was written in PHP doesn't mean that the code was unmaintainable. I don't know if it was or not. The problem they had was that it was unscalable, and they didn't do nothing about it. They wrote a PHP to c compiler, and that's a monumental task. So they paid their technical debt in a different way that they decided was the most efficient way for them to deal with it. If the problem isn't scalability, and is maintainability, you may not have that luxury. Unmaintainable code's problem is inherently in its structure, and the only solution for that is refactorization or a rewrite. The code may be so unmaintainable that even refactorization isn't really possible. The best offense is a good defense. Deal with technical debt from the get go. Sure, write your MVP in a weekend just to test it, but rewrite it early for maintainability while it's still small and possible.
  - aidos 13y ago
    Fair points. I guess I was reacting more to the fact that the original example probably wasn't of the scale (single person) to use as an example. The Facebook case is definitely different in that they were building new features too fast to keep up with. My project (single developer) is undergoing a big underlying change (switching from MongoDB to Postgresql) at the moment. I still need to keep development going on the live branch while I do this work. I'm doing it because I'm having maintainability issues with the data store that I've been putting off for a couple of months. It's as you say - make sure you refactor before you discover that refactoring is impossible. It's something I do regularly and my business partner has noticed that after a refactor of a component he gets other features faster so that's the only justification he needs.
cpeterso 13y ago
But are you adding new features to the old codebase? The challenge is when the rewrite takes longer than planned (e.g. Netscape) and your old product is no longer competitive but the replacement (which, as a rewrite, may not include any new features) is not ready.

Its not like I had to shut off the old site while I worked on the new codebase... The old codebase was running perfectly fine, up until I shut it off and replaced it with the new code.

aidos 13y ago

There are plenty of projects where by the time you've finished your rewrite the product will have moved on so far that you'll have to rewrite some again. I seem to recall Facebook making several attempts to rewrite in a language other than php but the codebase just evolved too quickly.

etler 13y ago
You don't rewrite for features. You rewrite for better maintainability and productivity. After your rewrite you shouldn't have to rewrite it again. The balancing act is that a rewrite should improve your implementation velocity, so while it may be a setback, your velocity should be much higher than your competitors, so over time you would be able to surpass them and then gain a lead they cannot beat thanks to your higher productivity. As the technical debt grows, your productivity will get slower and slower, so you won't be able to keep up with your competitors anyways. That's the gamble. Just because Facebook was written in PHP doesn't mean that the code was unmaintainable. I don't know if it was or not. The problem they had was that it was unscalable, and they didn't do nothing about it. They wrote a PHP to c compiler, and that's a monumental task. So they paid their technical debt in a different way that they decided was the most efficient way for them to deal with it. If the problem isn't scalability, and is maintainability, you may not have that luxury. Unmaintainable code's problem is inherently in its structure, and the only solution for that is refactorization or a rewrite. The code may be so unmaintainable that even refactorization isn't really possible. The best offense is a good defense. Deal with technical debt from the get go. Sure, write your MVP in a weekend just to test it, but rewrite it early for maintainability while it's still small and possible.
- aidos 13y ago
  Fair points. I guess I was reacting more to the fact that the original example probably wasn't of the scale (single person) to use as an example. The Facebook case is definitely different in that they were building new features too fast to keep up with. My project (single developer) is undergoing a big underlying change (switching from MongoDB to Postgresql) at the moment. I still need to keep development going on the live branch while I do this work. I'm doing it because I'm having maintainability issues with the data store that I've been putting off for a couple of months. It's as you say - make sure you refactor before you discover that refactoring is impossible. It's something I do regularly and my business partner has noticed that after a refactor of a component he gets other features faster so that's the only justification he needs.

cpeterso 13y ago

But are you adding new features to the old codebase? The challenge is when the rewrite takes longer than planned (e.g. Netscape) and your old product is no longer competitive but the replacement (which, as a rewrite, may not include any new features) is not ready.