Live data from Hacker News

On code quality: rewrite once

blog.tetrack.com

11–14 of 14 posts

Re: On code quality: rewrite once

#11
post #8

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…

I've noticed that python seems to stay cleaner than php would, but I'm not sure if it's the framework that's keeping things neat or the fact that php made it easier for the code to get dirty. It's also easy clean up a few parts of python without effecting too much where php might need a rewrite.

Re: On code quality: rewrite once

#12

Beware 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…

Not entirely true, even Brooks on "The Mythical Man Month" suggests to Plan to throw one away.

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

#13
post #7

Isn'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…

So you are working with a new technology stack and exploring new things... throwaway prototype is good when youa re doing something new. If you were versed witht he particular protocol, would you need to write to throwaway prototype ? I dont think so...

Re: On code quality: rewrite once

#14

Beware 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…

My understanding was that the second-system effect refers specifically to a junior programmer's second project, not the second iteration of any given project.

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.)

Post reply on HN