6 ms·

I'm curious about past examples of failures, can you provide some? Thanks!

bayindirh 6y ago
The thing with Owncloud/Nextcloud is the complexity of the system. When many users are working with the files at the same time, there's a lot of messaging going on in the backbone. If people are working in shared folders, that traffic goes visibly up. Messaging between systems is hard. When things are async, it's harder. When there's async concurrency, it becomes spicy. I'm managing a Nextcloud instance at the office. Even with this relatively mature state, it can bork itself pretty decently. Also, it has separation of responsibilities and a system admin is not an admin the traditional sense so, a lot of things are hidden between logs and other layers. Complicating this further by adding microservices is a brave idea at least. We're going to see what's going to happen. I hope they succeed but it's not a piece of cake.
fundatus 6y ago
Netscape for example: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- rimliu 6y ago
  It is telling when a single example is used for 20+ years.
  - superjan 6y ago
    I know 3 examples from personal experience. One that I worked on myself, that was scrapped before completion. Two other two were finished but they have severely impacted the business. But they are not so useful to share because you would not know about these products. My assumption is that we all know these kind of projects, but the Netscape story is a great reference because it explains why it is a bad idea.
  - mjw1007 6y ago
    And in hindsight it doesn't seem a terribly good example. Gecko was a technical success. On the non-technical side, it isn't at all clear that Netscape-the-company came out worse than it would have done if it had tried to stick with the buggy Netscape 4 rendering engine.
    - ThePhysicist 6y ago
      I'd argue that their attempted rewrite of Firefox in Rust also caused them to actually fall behind in terms of features and speed, which is reflected in the diminishing market share of Firefox. Technologically Rust is an awesome language and a boon to secure software development, I'm just not sure it was such a great idea for Mozilla to put so much energy into this, which could've gone into improving their main product instead.
      - ikt 6y ago
        I'd argue not because I switched from Firefox to Chrome at v1 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=10129030#post10129030 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=... Chrome was absolutely faster in web rendering than Firefox and more stable and the UX was cleaner, it made Firefox with its slow buggy performance and awful theme's look like myspace to Chromes facebook. I also remember being very frustrated with Firefox on Ubuntu ~10.04 at the time and when Chrome came along it was exactly what I'd been waiting for. Quantum/Servo/Rust/UI refreshes seems like this was Firefox catching up to Chrome v1 and honestly in 2020 it feels like Firefox has finally caught up significantly. It's still not as stable as Chrome but it's getting there, webrender is a massive leap forward in performance: https://testdrive-archive.azurewebsites.net/Performance/Chalkboard/ https://testdrive-archive.azurewebsites.net/Performance/Chal... That test is now showing at 6.65 seconds down from 45 seconds without it.
ThePhysicist 6y ago
There are many examples where complete rewrites have caused problems and killed or hampered companies, Netscape and Firefox come to mind. Regarding microservices I don't know any OS projects that have failed because of that (because there aren't many OS products that use a microservices architecture), but personally I witnessed many corporate software projects burn and fail when trying to rewrite an "ugly" but functional monolith as a collection of microservices. The thing is that the energy which you invest into rewriting your entire software in a new stack could also be invested into improving your existing stack. LAMP is not dead and actually evolving quite well, so there are definitely ways to improve the stability and speed of a LAMP application without rewriting it in Golang (even Facebook still uses PHP, albeit with some modifications). Having written extensive applications in both scripting languages and Golang I can say that the latter has its advantages but is also slower to develop in and in many respects not as agile as a scripting language like PHP or Python. Doing a rewrite of a popular project with thousands of deploys in the wild will also force you to split your attention between keeping the old system running and building the new one. Since most of your users will want to migrate from one system to the other without losing their existing data and configuration you'll have to ensure that there is a clear migration path that works, which can be quite hard. Also, all external systems that are interacting with existing installations (e.g. via APIs) will also need to be supported by the new system. In the end it might be possible to make it, but in my humble experience I think a complete rewrite is almost never a good idea and the energy you put into it is often better invested in making gradual improvements to your existing codebase. But that's just my 2c of course.
- rimliu 6y ago
  I'd say in your examples there were problems at companies which killed or hampered them and also caused rewrites.
  - ThePhysicist 6y ago
    Probably! From my experience I think the main problem is that developers often don't like to work with "legacy" code, where legacy means anything they didn't write themselves. Also, most developers tend to drastically underestimate the cost of a full rewrite as they don't know all the intricacies of the old system. From the outside most systems seem easy and straightforward, so people think they should be easy to rewrite. During the rewrite people then discover all the little edge cases that the legacy system handled and that they didn't think about. There are legitimate reasons to rewrite a system in a new language, it's not a a decision that should be taken lightly though. From a business perspective it's also very expensive, as having a team of 5-10 developers rewrite a system that already exists and works can cost millions of dollars, so you should have a really good reason and clear ROI objective when deciding to do this.
dosethree 6y ago
Incremental rewrites are just always better. The issue with full rewrites is that you have to rewrite everything - which I suppose sounds good to some engineers, but I dread being forced to spent weeks on parts of the product that are not an issue. Usually you do the rewrite to make things faster, more maintainable, and easier to add features. The issue is, the larger the rewrite, the worse you make all those things in the short-term.

The thing with Owncloud/Nextcloud is the complexity of the system. When many users are working with the files at the same time, there's a lot of messaging going on in the backbone. If people are working in shared folders, that traffic goes visibly up. Messaging between systems is hard. When things are async, it's harder. When there's async concurrency, it becomes spicy. I'm managing a Nextcloud instance at the office. Even with this relatively mature state, it can bork itself pretty decently. Also, it has separation of responsibilities and a system admin is not an admin the traditional sense so, a lot of things are hidden between logs and other layers. Complicating this further by adding microservices is a brave idea at least. We're going to see what's going to happen. I hope they succeed but it's not a piece of cake.

fundatus 6y ago

Netscape for example: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

rimliu 6y ago
It is telling when a single example is used for 20+ years.
- superjan 6y ago
  I know 3 examples from personal experience. One that I worked on myself, that was scrapped before completion. Two other two were finished but they have severely impacted the business. But they are not so useful to share because you would not know about these products. My assumption is that we all know these kind of projects, but the Netscape story is a great reference because it explains why it is a bad idea.
- mjw1007 6y ago
  And in hindsight it doesn't seem a terribly good example. Gecko was a technical success. On the non-technical side, it isn't at all clear that Netscape-the-company came out worse than it would have done if it had tried to stick with the buggy Netscape 4 rendering engine.
  - ThePhysicist 6y ago
    I'd argue that their attempted rewrite of Firefox in Rust also caused them to actually fall behind in terms of features and speed, which is reflected in the diminishing market share of Firefox. Technologically Rust is an awesome language and a boon to secure software development, I'm just not sure it was such a great idea for Mozilla to put so much energy into this, which could've gone into improving their main product instead.
    - ikt 6y ago
      I'd argue not because I switched from Firefox to Chrome at v1 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=10129030#post10129030 https://ubuntuforums.org/showthread.php?t=1398220&page=11&p=... Chrome was absolutely faster in web rendering than Firefox and more stable and the UX was cleaner, it made Firefox with its slow buggy performance and awful theme's look like myspace to Chromes facebook. I also remember being very frustrated with Firefox on Ubuntu ~10.04 at the time and when Chrome came along it was exactly what I'd been waiting for. Quantum/Servo/Rust/UI refreshes seems like this was Firefox catching up to Chrome v1 and honestly in 2020 it feels like Firefox has finally caught up significantly. It's still not as stable as Chrome but it's getting there, webrender is a massive leap forward in performance: https://testdrive-archive.azurewebsites.net/Performance/Chalkboard/ https://testdrive-archive.azurewebsites.net/Performance/Chal... That test is now showing at 6.65 seconds down from 45 seconds without it.

ThePhysicist 6y ago

There are many examples where complete rewrites have caused problems and killed or hampered companies, Netscape and Firefox come to mind. Regarding microservices I don't know any OS projects that have failed because of that (because there aren't many OS products that use a microservices architecture), but personally I witnessed many corporate software projects burn and fail when trying to rewrite an "ugly" but functional monolith as a collection of microservices. The thing is that the energy which you invest into rewriting your entire software in a new stack could also be invested into improving your existing stack. LAMP is not dead and actually evolving quite well, so there are definitely ways to improve the stability and speed of a LAMP application without rewriting it in Golang (even Facebook still uses PHP, albeit with some modifications). Having written extensive applications in both scripting languages and Golang I can say that the latter has its advantages but is also slower to develop in and in many respects not as agile as a scripting language like PHP or Python. Doing a rewrite of a popular project with thousands of deploys in the wild will also force you to split your attention between keeping the old system running and building the new one. Since most of your users will want to migrate from one system to the other without losing their existing data and configuration you'll have to ensure that there is a clear migration path that works, which can be quite hard. Also, all external systems that are interacting with existing installations (e.g. via APIs) will also need to be supported by the new system. In the end it might be possible to make it, but in my humble experience I think a complete rewrite is almost never a good idea and the energy you put into it is often better invested in making gradual improvements to your existing codebase. But that's just my 2c of course.

rimliu 6y ago
I'd say in your examples there were problems at companies which killed or hampered them and also caused rewrites.
- ThePhysicist 6y ago
  Probably! From my experience I think the main problem is that developers often don't like to work with "legacy" code, where legacy means anything they didn't write themselves. Also, most developers tend to drastically underestimate the cost of a full rewrite as they don't know all the intricacies of the old system. From the outside most systems seem easy and straightforward, so people think they should be easy to rewrite. During the rewrite people then discover all the little edge cases that the legacy system handled and that they didn't think about. There are legitimate reasons to rewrite a system in a new language, it's not a a decision that should be taken lightly though. From a business perspective it's also very expensive, as having a team of 5-10 developers rewrite a system that already exists and works can cost millions of dollars, so you should have a really good reason and clear ROI objective when deciding to do this.

dosethree 6y ago

Incremental rewrites are just always better. The issue with full rewrites is that you have to rewrite everything - which I suppose sounds good to some engineers, but I dread being forced to spent weeks on parts of the product that are not an issue. Usually you do the rewrite to make things faster, more maintainable, and easier to add features. The issue is, the larger the rewrite, the worse you make all those things in the short-term.