I find rewriting is more necessary in some languages than others. In Java, a rewrite was common. In Lisp, I don't think I've ever rewritten: the first dumbest prototype is just one continuous refactoring away from the final product. Python and Ruby were somewhere in between. I kind of have a vague feeling for why this would be true, but I can't quite put it into words. Maybe it has to do with how much structural stuf…
On code quality: rewrite once
11–14 of 14 posts
Re: On code quality: rewrite once
#12Beware of the dreaded Second System Effect. As in your second system is assured to be a disaster because you think you know enough but never really do. The practice of rewriting everything once assures that you will eternally experience the Second System Effect. OK to rewrite the really bad stuff that has a high density of bugs. OK to adapt your architecture if it really doesn't fit the problem domain you are discove…
So the suggestion isn't "the path to madness". The way to avoid the Second System Effect is simply to make a commitment not to develop new features on the rewrite. This second system will do the same as the first one except the code will be better.
An example of a successful project that did this is Subversion they pretty clearly said that they wanted to Create a CVS equivalent with certain annoyances corrected. That clear purpose and definition helped them avoid feature creep.
Re: On code quality: rewrite once
#13Isn't this what refactoring is ? As you mature as a coder, you will be able to write good code for certain standards which need not be thrown away. So having a look at the code and fixing the crappy portion will be more productive than throwing away the whole implementation. I think whole rewrite rule is useful when you start working on a new technology... but if you are using a stack for considerable amount of time,…
Well, maybe. I think it depends on the project. At the moment, I'm working interfacing a handheld device with a networking device. I quickly wrote a prototype to work out implementation details (since connectivity required using a particular protocol). That's not to say I didn't write parts of the prototype to be refactored or pulled out, but given that I had to do a fair amount of exploratory programming to determin…
Re: On code quality: rewrite once
#14Beware of the dreaded Second System Effect. As in your second system is assured to be a disaster because you think you know enough but never really do. The practice of rewriting everything once assures that you will eternally experience the Second System Effect. OK to rewrite the really bad stuff that has a high density of bugs. OK to adapt your architecture if it really doesn't fit the problem domain you are discove…
In any case, the solution proposed was not to avoid ever designing a second system, but to be mindful of this danger while doing so.
(Not that I'll follow this advice either. Deliberately forcing myself to solve the same problem the same way more than once would drive me nuts.)