5 ms·

I agree with "clean as you go", but I'm very cautious. Rewrites are scary and risky in legacy code. Usually I'll add a few unit tests to increase coverage and d

I agree with "clean as you go", but I'm very cautious. Rewrites are scary and risky in legacy code. Usually I'll add a few unit tests to increase coverage and de-risk the change I just made.

MaulingMonkey 9y ago
Leaving code as is can also be scary and risky. Being asked to overhaul an existing system on day 1 is scary though. I tend to hold off on rewrites until I can picture the new system - complete with a solid understanding of exactly how it will fix the problems of the old one. And yes, with good tests.
- zeta0134 9y ago
  Aye, I agree completely. When approaching a given rewrite, I'm very hesitant to go through with it unless I have a strong understanding of all the files I'm about to have to touch to fix the resulting compiler errors. Ideally this should be straightforward, but the tight coupling often observed in poorly maintained codebases can cause the most innocent of small changes to spiral out into the template metaprogramming circle of death. Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.
BurningFrog 9y ago
I think this epic rant against rewrites still is mostly valid 17 years later: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- btilly 9y ago
  It was wrong then and it is still wrong. First of all Netscape had the problem of incorporating opaque blobs from other sources. When they went open source, they couldn't keep those so ripped them out. Then the code didn't even compile. Secondly that Netscape release that he mocked? That was the start of Mozilla, Firefox, and so on. Third, how did Netscape survive? My impression from the sidelines is that it was a negotiation ploy from AOL. When their IE contract was up, they needed a viable alternative. In the end Microsoft let them continue using IE, PAID THEM MONEY, and had them shut down Netscape. They were laughing about this all of the way to the bank. And then Mozilla ate IE's lunch. There have been a lot of rewrites. Some succeed, some fail. But it isn't always a bad idea to do one. And Netscape was a necessary one that succeeded in every measure that it was supposed to.
  - EdSharkey 9y ago
    You are being charitable to Mozilla (the application suite). That was a bloated, buggy mess for years. I recall 2001-2003 was a really bleak time to be a Mozilla user. Firefox launched as a response to Mozilla and was more lean, but it wasn't until 2007 or 2008 that HTML5 features started trickling in and Firefox started to gain marketshare and developer mindshare for the advanced features it could offer. And that was when Chrome showed up. So from 1998-2008, Mozilla had an open season to gain ground on IE, and their marketshare only ever got as high as 30%. It was 2011 or 2012 that Chrome was stable enough and Google started their upgrade-to-Chrome adverts on google.com. And then Firefox faded back into it's 10% niche. I'm a developer, and my peers look at me like I'm a weirdo because I favor Firefox and do my primary development on it. That shouldn't have happened, Firefox should not be niche given the time they had to work. It is inspiring to me that the Mozilla project didn't fail and got so much love, but starting with that original Netscape codebase and the Gecko and XPCOM designs really hindered them. Mozilla missed out on offering a competing engine for Node.JS because their JS engine is so tightly coupled with the rest of the browser(?) - that's just one huge opportunity missed. Offering a competitive mobile OS at the advent of smartphones in the vein of WebOS is another, albeit less egregious, miss. The codebase just wasn't clean nor adaptable enough to break free of the desktop.
flukus 9y ago
Broadly I agree, lately though I've had to change some stuff that was tightly coupled to only slightly related code via generics and inheritance. Rewriting parts is the only way to disentangle things. If there is one thing that spaghetti programmers love it's inheritance.

I agree with "clean as you go", but I'm very cautious. Rewrites are scary and risky in legacy code. Usually I'll add a few unit tests to increase coverage and de-risk the change I just made.

MaulingMonkey 9y ago

Leaving code as is can also be scary and risky. Being asked to overhaul an existing system on day 1 is scary though. I tend to hold off on rewrites until I can picture the new system - complete with a solid understanding of exactly how it will fix the problems of the old one. And yes, with good tests.

zeta0134 9y ago
Aye, I agree completely. When approaching a given rewrite, I'm very hesitant to go through with it unless I have a strong understanding of all the files I'm about to have to touch to fix the resulting compiler errors. Ideally this should be straightforward, but the tight coupling often observed in poorly maintained codebases can cause the most innocent of small changes to spiral out into the template metaprogramming circle of death. Even then though, all is not lost! When faced with an architecture change that really should be made, but is too large to make right now, I make a note of it on a project board somewhere and now I have a new sub-task. Any time I touch code elsewhere, I work to reduce coupling and correct dependency issues, so that the original change is easier to make. By slowly cleaning up small parts of the code, I open the door to making the larger rewrite not quite so large when I get around to it, and hopefully improve the project's overall quality in the process. In this way, I create forward progress towards the end goal without needing to commit to all of it at once.

BurningFrog 9y ago

I think this epic rant against rewrites still is mostly valid 17 years later: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

btilly 9y ago
It was wrong then and it is still wrong. First of all Netscape had the problem of incorporating opaque blobs from other sources. When they went open source, they couldn't keep those so ripped them out. Then the code didn't even compile. Secondly that Netscape release that he mocked? That was the start of Mozilla, Firefox, and so on. Third, how did Netscape survive? My impression from the sidelines is that it was a negotiation ploy from AOL. When their IE contract was up, they needed a viable alternative. In the end Microsoft let them continue using IE, PAID THEM MONEY, and had them shut down Netscape. They were laughing about this all of the way to the bank. And then Mozilla ate IE's lunch. There have been a lot of rewrites. Some succeed, some fail. But it isn't always a bad idea to do one. And Netscape was a necessary one that succeeded in every measure that it was supposed to.
- EdSharkey 9y ago
  You are being charitable to Mozilla (the application suite). That was a bloated, buggy mess for years. I recall 2001-2003 was a really bleak time to be a Mozilla user. Firefox launched as a response to Mozilla and was more lean, but it wasn't until 2007 or 2008 that HTML5 features started trickling in and Firefox started to gain marketshare and developer mindshare for the advanced features it could offer. And that was when Chrome showed up. So from 1998-2008, Mozilla had an open season to gain ground on IE, and their marketshare only ever got as high as 30%. It was 2011 or 2012 that Chrome was stable enough and Google started their upgrade-to-Chrome adverts on google.com. And then Firefox faded back into it's 10% niche. I'm a developer, and my peers look at me like I'm a weirdo because I favor Firefox and do my primary development on it. That shouldn't have happened, Firefox should not be niche given the time they had to work. It is inspiring to me that the Mozilla project didn't fail and got so much love, but starting with that original Netscape codebase and the Gecko and XPCOM designs really hindered them. Mozilla missed out on offering a competing engine for Node.JS because their JS engine is so tightly coupled with the rest of the browser(?) - that's just one huge opportunity missed. Offering a competitive mobile OS at the advent of smartphones in the vein of WebOS is another, albeit less egregious, miss. The codebase just wasn't clean nor adaptable enough to break free of the desktop.

flukus 9y ago

Broadly I agree, lately though I've had to change some stuff that was tightly coupled to only slightly related code via generics and inheritance. Rewriting parts is the only way to disentangle things. If there is one thing that spaghetti programmers love it's inheritance.