3 ms·

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 t

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. Because that's exactly what someone else is going to do. The company that makes the product that competes with yours is unlikely to have picked your product at random and simply decided to compete against it on a whim. There's a good chance they've been using your product and have become so frustrated with it's shortcomings that they've had a crack a building there own version. They've been on your support forums that detail every bug and bad descision, they've read the blog post detailing exactly what is wrong with your features and how they could be done better. They've stared at their screen in a full on rage wondering why the hell your product doesn't do things in a way that makes sense. They have their own experience and they are not afraid to use it. There could be one, tens or hundreds of people who decide to do this. Many will fail, but if one succeeds then you have a serious problem. The continued success of your product can no longer rely on it's features unless you're prepared to make some fundamental changes. Only now you have a deadline, whereas before you could have worked at your own pace. You're right when you say your legacy code is your greatest asset. It's proof of what is a good idea and what is a bad idea. But that doesn't mean you should keep it around any longer than you have to.

JohnBooty 14y ago
"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." http://www.joelonsoftware.com/articles/fog0000000069.html 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.

JohnBooty 14y ago

"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." http://www.joelonsoftware.com/articles/fog0000000069.html 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.