[dhh]

If you rewrite your code base to do the same things as the old code base was doing, yes, you're doing it wrong. If you rewrite your code base to do different things, you might very well be very right. (Depending on whether the market is more interested in those new things than the old things).

[kenrikm]

I agree, I actually just threw out a bunch of code and started with a fresh base with a much cleaner OOP structure and could not be happier with my results so far. Things that I was struggling with before are now super simple because everything is properly segmented. The whole process only took two days as many of my classes could be reused and I just needed to fix how they were interacting. Then again I was just correcting my quick and dirty code, I don't know if I would have done the same with a production application as it would be safer to just work on both at the same time until it was in good shape to cleanly replace the first.

An example of when a rewrite goes bad is Final Cut Pro X.. Apple really leaned a lesson with that fiasco.

[ternaryoperator]

I don't think Joel is arguing against throwing out old code here and there. Especially, if it only takes two days to replace it. I think most devs would view that as an inevitable step on large projects. Especially on projects that head into uncharted waters, where the chances of getting things right the first time are almost nil.

[SonicSoul]

this is a risky territory for a whole set of reasons. those different things you're adding might change the way customers use your product, and more often than not, their opinion will differ on how useful the changes are. often times products lose features in such a rewrite. these features may seem insignificant to you, but may mean the world to existing users.

[dhh]

Which is why in our case we're keeping both the old and the new product around.

[jgarmon]

We did precisely the same thing at our company about 18 months ago. Our original codebase just couldn't scale. It was a great MVP platform, and we learned a great deal from it, but it simply couldn't handle load, sophisticated billing options, or any reasonable expansion of the product functionality.

That said, we left the new and old systems running in parallel (all new users were directed to the new platform) for over a year before we even informed users we were shutting it off, then gave them another six months to migrate. And we never purged the old data; it's in cold storage in case someone ever comes looking for it.

Rewriting the codebase isn't something you should take lightly, but "never" is pretty damn strong word.

[hythloday]

Then it seems like you're not really rewriting as Joel defines it, you're launching a new product (it does new things, and it doesn't replace the old one). I guess it then becomes a question of effort spent in cannibalizing your own product vs. the income the new version brings, which is a very different equation for Basecamp and the products Joel talks about.