Re:LibreOffice: cleaning and re-factoring a giant code-base ...
by JohnBooty on Sunday February 17, 2013 @12:50PM
(#5235987)
"It seems there's an assumption here that building your product again means throwing out all of your experience. What I thought would have been self evident is that by starting again, you bring to the table all your experience and you harness that to build a better product"
Ideally, yes! Realistically, there's always some hairy, gnarly wisdom "baked into" the code.
The definitive article is Joel Sposky's article on the perils of writing from scratch. If you only want to read a few paragraphs:
"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."
Ideally, yeah, you take that wisdom with you to the new project but realistically (even if you've followed great documentation practices, etc, for all of those hairy kludges) the rewrite-from-scratch is never as easy as one thinks.
Ideally, yes! Realistically, there's always some hairy, gnarly wisdom "baked into" the code.
The definitive article is Joel Sposky's article on the perils of writing from scratch. If you only want to read a few paragraphs:
"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."
http://www.joelonsoftware.com/articles/fog0000000069.html
Ideally, yeah, you take that wisdom with you to the new project but realistically (even if you've followed great documentation practices, etc, for all of those hairy kludges) the rewrite-from-scratch is never as easy as one thinks.