5 ms·

I don't quite agree with you. Rewriting software in general removes a lot of security related bugs because the new design is more clear. Of course some new ones

I don't quite agree with you. Rewriting software in general removes a lot of security related bugs because the new design is more clear. Of course some new ones will be introduced and need to be weeded out but I think those kind of bugs are the minority and can be weeded out in a fraction of the time it took for the original software. On the other hand it introduces a lot of usability bugs. Many things are they way they are because of many bug reports of many users that all have their own workflows and usage patterns. These kinds of bugs are harder to weed out. Also they can lead to early refusal by the users of the old software. Then there is the Version-2 effect of packing in too many new features and deliberately introducing fundamental changes that break everything at once. This, in my opinion, is the worst about a complete rewrite.

jstimpfle 5y ago
c.f. "Second System Effect". How many examples of successful rewrites of large systems can you come up with? The new design will only be better if there were actual lessons learned, which probably at least requires that it be done by the same people. Also, compared to incremental development I can attest that a big-bang rewrite takes a lot of grit to do all the grunt work again, replacing perfectly working and now rather boring infrastructure. It's very hard to suffer through it, even if some other parts could be substantially better.
- btilly 5y ago
  Ironically the second system effect was named by Fred Brooks in The Mythical Man-Month. It is ironic because his background was heading development of a large, and ultimately successful, second system. Namely IBM's OS/360. Moving on, Brooks correctly identified that third systems do much better than second systems. (The pattern is that the first system suffers from your general incompetence, the second system tries to over-abstract and shove too many features in there, and the third system is the first where you can strike a pragmatic balance.) Still Mozilla/Firefox was a rewrite of Netscape, Python 3 a rewrite of Python 2, Doom a rewrite of Wolfenstein 3D, and so on. Many companies have a history of their third version of software being significantly better, meaning that they survived the first and second systems to get there. For example the first successful version of Windows was Windows 3.1. There is another kind of successful rewrite, which is a copycat product. For example MS Excel is a rewrite of Lotus 1-2-3 and Microsoft Word is a rewrite of WordPerfect. And, to keep this from just being picking on Microsoft, Google's Dalvik was a rewrite of the JVM. (And then Oracle sued...)
- mamcx 5y ago
  > How many examples of successful rewrites of large systems can you come up with? Considering the size of the software industry... a LOT. I have done a DOZEN of rewrites from langs to langs and each (bar one) have been successfully. But success is not proclaimed, how failures are... --- A good rewrite is just a good refactoring but with a higher chance of success. A bad rewrite is mostly an amplification of larger issues in the org/group, lack of experience (yeah, your first one is likely to fail!) or lack of clear goals. Also, rewriting a terrible designed software to another language without fix the terrible designs WILL be terrible. --- On this matter, considering the calibre of the people that build C/C++ things at the core AND the calibre of Rust/ADA and other few tools + the enormous resources of the companies behind them, a rewrite must be successfully. BUt is not, and when you zoom at the postmortens, how much is truly to blame for the langs or tools? Not much. * And if the tools have a big part of blame, is beause was not the correct tool for the job... so, is part of the larger issues in the org/group"
  - jstimpfle 5y ago
    > I have done a DOZEN of rewrites from langs to langs and each (bar one) have been successfully. How large were these systems? How many developers? How long did the rewrite take? > A good rewrite is just a good refactoring but with a higher chance of success Are you saying it's not a restart from scratch? In that case I don't call that a rewrite. Maybe a "rewrite of this or that module" which is more likely to succeed.
    - mamcx 5y ago
      Most have been mainly me. I normally was hired and get stuck doing this kind of stuff until the other team was supporting the old project. Along the way was the one that push source control, tickets system, crude CI to the larger team... Maybe being solo or being part of a small team is good after all. A rewrite is normally called because of a BIG mess, and most of that is simplify stuff. My niche is "enterprise" software, where is HIGHLY dependent in niche details from non-developers, so having not clarity of what the software actually do, why or how, and neither the people that use it understand it. Zero or useless documentation, and all the bad red flags you think off. 2 have been large-ish (I think from the POV of most people in my country are large but not from the POV of people that work in companies like google). One was in a startup (at the time one of the largest paying customers of Google cloud). The other was in succession of failed attempts between maybe 2 or 3 groups of developers (the one before me was a big consultant company with a large team that left me with a BIIIIG mess!). The longest rewrite was 2 years (from FoxPro to .NET, an ERP, 1-5 devs, only me all the time p.d: just the core, the rest was later). This was a near failure that was turned around. The one were we failed was by lack of properly understand the severity of downtime for the customers and not provide a transparent migration, in real time, of the data. The cost in days - for the testing, upgrade and all that) cost them more money than they pay for the new software. The company I work back them get broke working for the government in another contract and the customer was not willing to recover from it. Is certainly the most sad history of my career because it was not that impossible to turn the ship around - the software was ready, only need to retrofit how move the data without downtime-, but everything go under in no time...
AnimalMuppet 5y ago
> Rewriting software in general removes a lot of security related bugs because the new design is more clear. That seems unduly optimistic. A re-write may keep the same design because it's known to work. Or it may try to make a better one. That new design can easily fail to actually be better. You can have the version 2 effect in the design, not just in the features.

jstimpfle 5y ago

c.f. "Second System Effect". How many examples of successful rewrites of large systems can you come up with? The new design will only be better if there were actual lessons learned, which probably at least requires that it be done by the same people. Also, compared to incremental development I can attest that a big-bang rewrite takes a lot of grit to do all the grunt work again, replacing perfectly working and now rather boring infrastructure. It's very hard to suffer through it, even if some other parts could be substantially better.

btilly 5y ago
Ironically the second system effect was named by Fred Brooks in The Mythical Man-Month. It is ironic because his background was heading development of a large, and ultimately successful, second system. Namely IBM's OS/360. Moving on, Brooks correctly identified that third systems do much better than second systems. (The pattern is that the first system suffers from your general incompetence, the second system tries to over-abstract and shove too many features in there, and the third system is the first where you can strike a pragmatic balance.) Still Mozilla/Firefox was a rewrite of Netscape, Python 3 a rewrite of Python 2, Doom a rewrite of Wolfenstein 3D, and so on. Many companies have a history of their third version of software being significantly better, meaning that they survived the first and second systems to get there. For example the first successful version of Windows was Windows 3.1. There is another kind of successful rewrite, which is a copycat product. For example MS Excel is a rewrite of Lotus 1-2-3 and Microsoft Word is a rewrite of WordPerfect. And, to keep this from just being picking on Microsoft, Google's Dalvik was a rewrite of the JVM. (And then Oracle sued...)
mamcx 5y ago
> How many examples of successful rewrites of large systems can you come up with? Considering the size of the software industry... a LOT. I have done a DOZEN of rewrites from langs to langs and each (bar one) have been successfully. But success is not proclaimed, how failures are... --- A good rewrite is just a good refactoring but with a higher chance of success. A bad rewrite is mostly an amplification of larger issues in the org/group, lack of experience (yeah, your first one is likely to fail!) or lack of clear goals. Also, rewriting a terrible designed software to another language without fix the terrible designs WILL be terrible. --- On this matter, considering the calibre of the people that build C/C++ things at the core AND the calibre of Rust/ADA and other few tools + the enormous resources of the companies behind them, a rewrite must be successfully. BUt is not, and when you zoom at the postmortens, how much is truly to blame for the langs or tools? Not much. * And if the tools have a big part of blame, is beause was not the correct tool for the job... so, is part of the larger issues in the org/group"
- jstimpfle 5y ago
  > I have done a DOZEN of rewrites from langs to langs and each (bar one) have been successfully. How large were these systems? How many developers? How long did the rewrite take? > A good rewrite is just a good refactoring but with a higher chance of success Are you saying it's not a restart from scratch? In that case I don't call that a rewrite. Maybe a "rewrite of this or that module" which is more likely to succeed.
  - mamcx 5y ago
    Most have been mainly me. I normally was hired and get stuck doing this kind of stuff until the other team was supporting the old project. Along the way was the one that push source control, tickets system, crude CI to the larger team... Maybe being solo or being part of a small team is good after all. A rewrite is normally called because of a BIG mess, and most of that is simplify stuff. My niche is "enterprise" software, where is HIGHLY dependent in niche details from non-developers, so having not clarity of what the software actually do, why or how, and neither the people that use it understand it. Zero or useless documentation, and all the bad red flags you think off. 2 have been large-ish (I think from the POV of most people in my country are large but not from the POV of people that work in companies like google). One was in a startup (at the time one of the largest paying customers of Google cloud). The other was in succession of failed attempts between maybe 2 or 3 groups of developers (the one before me was a big consultant company with a large team that left me with a BIIIIG mess!). The longest rewrite was 2 years (from FoxPro to .NET, an ERP, 1-5 devs, only me all the time p.d: just the core, the rest was later). This was a near failure that was turned around. The one were we failed was by lack of properly understand the severity of downtime for the customers and not provide a transparent migration, in real time, of the data. The cost in days - for the testing, upgrade and all that) cost them more money than they pay for the new software. The company I work back them get broke working for the government in another contract and the customer was not willing to recover from it. Is certainly the most sad history of my career because it was not that impossible to turn the ship around - the software was ready, only need to retrofit how move the data without downtime-, but everything go under in no time...

AnimalMuppet 5y ago

> Rewriting software in general removes a lot of security related bugs because the new design is more clear. That seems unduly optimistic. A re-write may keep the same design because it's known to work. Or it may try to make a better one. That new design can easily fail to actually be better. You can have the version 2 effect in the design, not just in the features.