3 ms·

When a developer says "I am going to rewrite ..." you have to question why? If you were not doing this "rewrite" then what else would you be doing? Refactor is

When a developer says "I am going to rewrite ..." you have to question why? If you were not doing this "rewrite" then what else would you be doing? Refactor is usually a term used to minimally modify legacy code to allow new functionality to be added. Rewriting implies rewriting legacy code (regressions) and wasting time. If a developer says "it's the only way" then you need to be sure you can trust their judgement.

esperent 6y ago
I frequently write code that is publically available on GitHub and used by other people. Sometimes my first attempt at structuring the code works out well (more and more often as I grow in experience). Sometimes... Not so much. Usually a refactor is enough, but occasionally I have to buckle down and say, to be ready for public consumption, a rewrite would be faster.
to11mtm 6y ago
I tend to agree. Part of the problem is when developers get thrown into unfamiliar code bases but can't read code well, they may think about just doing a rewrite. But really, Thoughtful refactoring is better. And as another comment noted, in many cases good architecture comes from learning by past mistakes of yourself and others. OTOH, there are edge cases. I'm currently finishing up a rewrite, but it was due to the existing software being written in a language that most people aren't proficient in and isn't really the norm in our company. I've witnessed but did not participate in two rewrites. In one case, a company wanted to switch languages and databases (got sick of oracle licensing.) In another case, the company had a pretty good justification for a rewrite; the system was a monstrosity of .NET on top of VB6. In fact, in this case after the initial rewrite attempt failed and there was a change in management we pivoted strategy. Instead of trying to rewrite the world we would just continue to refactor things as we made changes to those modules, and only hard-rewrite the VB6 code. I don't know if they're still doing that, but it was a -lot- more productive than the rewrite team spending a year producing nothing that ever made it to production.
ydnaclementine 6y ago
> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
Chris_Newton 6y ago
Rewriting implies rewriting legacy code (regressions) and wasting time. This isn’t necessarily true. A few years ago, we rewrote a large part of a web-based UI. The original implementation was a Java applet, a reasonable choice for an interactive diagram at the time it was first written. However, over time the applet had become a liability because browsers were planning to drop support, and in the meantime some useful alternative technologies had become available. In a situation where you are porting an established system to run on a new platform, rewriting really is the only way and therefore isn’t a waste of time.
- sys_64738 6y ago
  This is definitely an interesting case where your product suffers through external factors. Things like languages being EOL'd (python), technology becomes obsolete (like you mention here), vendor forcing change through API and security change through OS upgrade (iOS), and security CVE issues. These all cause sustaining to be done to older code in unexpected ways.
commandlinefan 6y ago
I often suggest rewriting (or large-scale refactoring) to modularize big balls of mud to permit automated testing. I can always justify this by pointing out how much time is wasted doing manual testing, as well as how much time is wasted starting up a full-blown instance of an app and then navigating to where the problem is just to troubleshoot something. In my experience, though, "rewriting is wasting time" types reject that reasoning because they don't really have a good handle of software engineering concepts.

esperent 6y ago

I frequently write code that is publically available on GitHub and used by other people. Sometimes my first attempt at structuring the code works out well (more and more often as I grow in experience). Sometimes... Not so much. Usually a refactor is enough, but occasionally I have to buckle down and say, to be ready for public consumption, a rewrite would be faster.

to11mtm 6y ago

I tend to agree. Part of the problem is when developers get thrown into unfamiliar code bases but can't read code well, they may think about just doing a rewrite. But really, Thoughtful refactoring is better. And as another comment noted, in many cases good architecture comes from learning by past mistakes of yourself and others. OTOH, there are edge cases. I'm currently finishing up a rewrite, but it was due to the existing software being written in a language that most people aren't proficient in and isn't really the norm in our company. I've witnessed but did not participate in two rewrites. In one case, a company wanted to switch languages and databases (got sick of oracle licensing.) In another case, the company had a pretty good justification for a rewrite; the system was a monstrosity of .NET on top of VB6. In fact, in this case after the initial rewrite attempt failed and there was a change in management we pivoted strategy. Instead of trying to rewrite the world we would just continue to refactor things as we made changes to those modules, and only hard-rewrite the VB6 code. I don't know if they're still doing that, but it was a -lot- more productive than the rewrite team spending a year producing nothing that ever made it to production.

ydnaclementine 6y ago

> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

Chris_Newton 6y ago

Rewriting implies rewriting legacy code (regressions) and wasting time. This isn’t necessarily true. A few years ago, we rewrote a large part of a web-based UI. The original implementation was a Java applet, a reasonable choice for an interactive diagram at the time it was first written. However, over time the applet had become a liability because browsers were planning to drop support, and in the meantime some useful alternative technologies had become available. In a situation where you are porting an established system to run on a new platform, rewriting really is the only way and therefore isn’t a waste of time.

sys_64738 6y ago
This is definitely an interesting case where your product suffers through external factors. Things like languages being EOL'd (python), technology becomes obsolete (like you mention here), vendor forcing change through API and security change through OS upgrade (iOS), and security CVE issues. These all cause sustaining to be done to older code in unexpected ways.

commandlinefan 6y ago

I often suggest rewriting (or large-scale refactoring) to modularize big balls of mud to permit automated testing. I can always justify this by pointing out how much time is wasted doing manual testing, as well as how much time is wasted starting up a full-blown instance of an app and then navigating to where the problem is just to troubleshoot something. In my experience, though, "rewriting is wasting time" types reject that reasoning because they don't really have a good handle of software engineering concepts.