9 ms·

Really glad to see this rebuttal. I understand the sentiment behind the post from the other day, and most days when I look at the repos I work on, I feel the sa

Really glad to see this rebuttal. I understand the sentiment behind the post from the other day, and most days when I look at the repos I work on, I feel the same way, but it just isn't true in a general sense. We write code because it is _bottom-line_, valuable as fuck. It really boils down to: time is the most expensive asset around. This debate does bring up a very interesting thing though: At what point do you ditch the old code and re-write the whole damn thing? (I am currently struggling with this)

_heimdall 3y ago
If I have the time to plan ahead, I much prefer to prepare with a full test suite that I fan rely on before considering a rewrite. Rewrites are difficult to estimate, difficult to pull off, and often demotivating as the work drags on. Having a suite of test coverage that I can reuse for the rewrite both gives me an easy check to make sure functionality isn't lost and a cheap bit of motivation as I see tests slowly turning green.
_fat_santa 3y ago
> This debate does bring up a very interesting thing though: At what point do you ditch the old code and re-write the whole damn thing? (I am currently struggling with this) According to Joel Spolsky, it's something you should never do[1]. [1]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- washedup 3y ago
  Liking this post, thanks for sharing.
- rm_-rf_slash 3y ago
  In my experience, the urge to refactor everything stems from one or a few really really badly coded features that waft their smell to the rest of the codebase. The limited from-scratch refactor can be painful in the short term, but after it’s done you realize how much more manageable other features are because you’re no longer mentally burdened by the worst of the codebase.
- alex_lav 3y ago
  And as with all things, "Never" actually means "Sometimes but extremely rarely".
zerbinxx 3y ago
Imo the only time you should do this is when you need features/upgrades that the current paradigm doesn’t support, the existing project is well tested, and the “rewrite” can be done in successive smaller changesets which don’t break everything.

_heimdall 3y ago

If I have the time to plan ahead, I much prefer to prepare with a full test suite that I fan rely on before considering a rewrite. Rewrites are difficult to estimate, difficult to pull off, and often demotivating as the work drags on. Having a suite of test coverage that I can reuse for the rewrite both gives me an easy check to make sure functionality isn't lost and a cheap bit of motivation as I see tests slowly turning green.

_fat_santa 3y ago

> This debate does bring up a very interesting thing though: At what point do you ditch the old code and re-write the whole damn thing? (I am currently struggling with this) According to Joel Spolsky, it's something you should never do[1]. [1]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

washedup 3y ago
Liking this post, thanks for sharing.
rm_-rf_slash 3y ago
In my experience, the urge to refactor everything stems from one or a few really really badly coded features that waft their smell to the rest of the codebase. The limited from-scratch refactor can be painful in the short term, but after it’s done you realize how much more manageable other features are because you’re no longer mentally burdened by the worst of the codebase.
alex_lav 3y ago
And as with all things, "Never" actually means "Sometimes but extremely rarely".

zerbinxx 3y ago

Imo the only time you should do this is when you need features/upgrades that the current paradigm doesn’t support, the existing project is well tested, and the “rewrite” can be done in successive smaller changesets which don’t break everything.