6 ms·

In rewriting projects, I often find that as I rewrite them, I can knock out requested features along the way. I've taken this approach when fixing up some of my

In rewriting projects, I often find that as I rewrite them, I can knock out requested features along the way. I've taken this approach when fixing up some of my old personal codebases. It's a two birds one stone approach; it takes me just as long to fix code in the old framework as it does to rewrite the code in the new framework without the buggy behavior, so where possible I do that. We had a similar practice in the restaurant world before I found work as a programmer, and we called it "clean as you go." I think it's quite appropriate. The bug reports will always be there, the feature requests mountainous, and yet the messes don't clean themselves. There must be balance. Do what needs to be done, but make a point to improve your codebase with every new change. Prefer consistency over new hotness, and ease of maintenance over unreadable micro-optimizations. Be a positive force in your codebase, and future developers, especially including yourself, will appreciate your efforts.

richdougherty 9y ago
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.
Benjammer 9y ago
The Boy Scout Rule[0] [0]: http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule http://programmer.97things.oreilly.com/wiki/index.php/The_Bo...
angry_octet 9y ago
Clean as you go sure, but in a twisted and janky codebase, full of absurdist abstract factories and eerie hall-of-mirrors template meta-programming, you have watch your step. Deep, deep in the code there are bugs which have lain undististurbed for eons. Scrape away some cmake pus, sprinkle in the mandatory security fixes, sure no problem. But dig to deep with the 'WTF were they thinking reimplementing the preprocessor?' shovel and you'll wake the helter-skelter bugs from their heisencave into reality. Also, you mustn't awake the Balrog. The possibly bearded old programmer, he used to be a Hero programmer, a mythical 10x coder, and he thinks he owns ALL THE CODE. He will revert your SCCS checkin and put the GOTOs back in the code.

richdougherty 9y ago

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.

Benjammer 9y ago

The Boy Scout Rule[0] [0]: http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule http://programmer.97things.oreilly.com/wiki/index.php/The_Bo...

angry_octet 9y ago

Clean as you go sure, but in a twisted and janky codebase, full of absurdist abstract factories and eerie hall-of-mirrors template meta-programming, you have watch your step. Deep, deep in the code there are bugs which have lain undististurbed for eons. Scrape away some cmake pus, sprinkle in the mandatory security fixes, sure no problem. But dig to deep with the 'WTF were they thinking reimplementing the preprocessor?' shovel and you'll wake the helter-skelter bugs from their heisencave into reality. Also, you mustn't awake the Balrog. The possibly bearded old programmer, he used to be a Hero programmer, a mythical 10x coder, and he thinks he owns ALL THE CODE. He will revert your SCCS checkin and put the GOTOs back in the code.