Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long tim…
For big projects, with multiple people and man-years of work, sure. Don’t start from scratch. But in my humble opinion, those projects shouldn’t really exist. Instead they should be atomic, made up of small page-length units which individually can be scraped and rebuilt.
For small projects, rewriting is often superb. It allows us to reorganize a mess, apply new knowledge, add neat features and doodads, etc.
It’s a way of saying “these are wrong and should be deprecated.”
They aren’t wrong. No one in their right mind just throws away years of work delivering a stable production project just because a random clueless person in the internet said something. It’s lunacy.
You think web browsers should not exist? How do you write Google Chrome, and all of it’s dependencies, in one page of code?
I think you’re miss-understanding the article. Joel didn’t say you should never rewrite an individual component in your code, he was saying you should never throw out an entire project (all of the components) and start from scratch.
He also wasn’t talking about “multiple people and man-years of work”. He was talking much larger projects. How many people have contributed Chrome? Not just direct contributions writing lines of code, but indirect contributions such as reporting bugs or writing documentation on how it works?
If Google were to start over, all of that would be thrown out. It just can’t be done.
All you can really do is what Microsoft did with IE / Edge. Edge was a fork of Chromium which was a fork of WebKit which was a fork of KTHML which was a fork of the KDE HTML Widget. Which dates back to 1996. Internet Explorer started in 1995. Microsoft didn’t start Edge from scratch, they basically shifted their team of developers over to another project that was the same age.
The smaller the project, the easier it is to do a full rewrite but realistically it’s almost never a good idea unless your product is very young.
If Google were to start over, all of that would be thrown out. It just can’t be done.
To stress the importance of this very basic fact, people need to understand that even Google, a company with virtually limitless resources to rearchitect and rewrite any and all type of software project, made the call to avoid using major features offered by some programming languages, such as C++'s exceptions, because it could have unintended consequences on the company’s legacy code base which they could not rewrite.
And here we are, reading fantastic claims over how complete rewrites are reasonable things while flipping compiler flags to harden legacy projects is unheard of.
I’ve found that big projects need refactoring without replacement, as Joel says. Bind and sudo and even sendmail have value in this world (the latter for versatility) that cannot be easily replicated without massive cost and decades of maintenance amid real attacks.
But yeah, trivial stuff can be rewritten and exhaustively tested at occasionally a cheaper cost where it can provide value to the enterprise that will one day out-balance its rebuild cost.
This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.
Pretending those don’t exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).
Replace functions replace files and rewrite modules, that’s expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment…?
For small projects, rewriting is often superb. It allows us to reorganize a mess, apply new knowledge, add neat features and doodads, etc.
This. I’m coding to contribute to a open-source software with very small amount of coders, and with a non-mainstream Domain-Specific Language. A lot of the code I did before has been proven to work from times to time, but they all could benefit from better outputs and better GUI. So, I end up reengineering the entire and that’ll take a really long time, however, I do a lot of tests to ensure it works.
Boy do I ever disagree with this.
For big projects, with multiple people and man-years of work, sure. Don’t start from scratch. But in my humble opinion, those projects shouldn’t really exist. Instead they should be atomic, made up of small page-length units which individually can be scraped and rebuilt.
For small projects, rewriting is often superb. It allows us to reorganize a mess, apply new knowledge, add neat features and doodads, etc.
What’s the point of your opinion if not only do these projects exist but they are also pervasive?
You cannot wish things away and pretend reality is something different.
“I reject your reality and substitute my own.”
Did you just stop reading there? I was saying those projects should have atomic architectures so that “rewrite small parts when needed” can happen
It’s a way of saying “these are wrong and should be deprecated.”
They aren’t wrong. No one in their right mind just throws away years of work delivering a stable production project just because a random clueless person in the internet said something. It’s lunacy.
This thread is a great example to why despite sharing knowledge we continually fail to write software effectively.
The person you’re arguing with just doesn’t get it. They have their own reality.
You think web browsers should not exist? How do you write Google Chrome, and all of it’s dependencies, in one page of code?
I think you’re miss-understanding the article. Joel didn’t say you should never rewrite an individual component in your code, he was saying you should never throw out an entire project (all of the components) and start from scratch.
He also wasn’t talking about “multiple people and man-years of work”. He was talking much larger projects. How many people have contributed Chrome? Not just direct contributions writing lines of code, but indirect contributions such as reporting bugs or writing documentation on how it works?
If Google were to start over, all of that would be thrown out. It just can’t be done.
All you can really do is what Microsoft did with IE / Edge. Edge was a fork of Chromium which was a fork of WebKit which was a fork of KTHML which was a fork of the KDE HTML Widget. Which dates back to 1996. Internet Explorer started in 1995. Microsoft didn’t start Edge from scratch, they basically shifted their team of developers over to another project that was the same age.
The smaller the project, the easier it is to do a full rewrite but realistically it’s almost never a good idea unless your product is very young.
They actually did somewhat start Edge from scratch originally. They made EdgeHTML as a rewrite of the IE 11 trident engine.
In the end they abandoned it and moved over to chromium. One of the reasons being Google intentionally breaking their sites for EdgeHTML.
To stress the importance of this very basic fact, people need to understand that even Google, a company with virtually limitless resources to rearchitect and rewrite any and all type of software project, made the call to avoid using major features offered by some programming languages, such as C++'s exceptions, because it could have unintended consequences on the company’s legacy code base which they could not rewrite.
And here we are, reading fantastic claims over how complete rewrites are reasonable things while flipping compiler flags to harden legacy projects is unheard of.
I’ve found that big projects need refactoring without replacement, as Joel says. Bind and sudo and even sendmail have value in this world (the latter for versatility) that cannot be easily replicated without massive cost and decades of maintenance amid real attacks.
But yeah, trivial stuff can be rewritten and exhaustively tested at occasionally a cheaper cost where it can provide value to the enterprise that will one day out-balance its rebuild cost.
This is a weird take given that the majority of projects relevant to this article are massive projects with hundreds or thousands of developers working on them, over time periods that can measure in decades.
Pretending those don’t exist and imagining fantasy scenarios where all large projects are made up of small modular pieces (while conveniently making no mention to all of the new problems this raises in practice).
Replace functions replace files and rewrite modules, that’s expected and healthy for any project. This article is referring to the tendency for programmers to believe that an entire project should be scrapped and rewritten from scratch. Which seems to have nothing to do with your comment…?
This. I’m coding to contribute to a open-source software with very small amount of coders, and with a non-mainstream Domain-Specific Language. A lot of the code I did before has been proven to work from times to time, but they all could benefit from better outputs and better GUI. So, I end up reengineering the entire and that’ll take a really long time, however, I do a lot of tests to ensure it works.