

On code quality: rewrite once - Tihy
http://blog.tetrack.com/2009/01/on-code-quality-rewrite-once/
All you have to do is delete your first implementation and rewrite all the code from scratch. The main reason for this is that you can focus on code quality without being constrained by the existing implementation.
======
ken
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 stuff I have to
write, or how directly I can express my program in the first place. Thoughts?

~~~
pyroman
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.

------
vivekkhurana
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, then refactoring is the way to improve the code
quality.

~~~
bmj
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 determine the best
implementation, much of the prototype code will be thrown away.

~~~
vivekkhurana
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...

------
lgriffith
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
discovering and you really can make it simpler. OK to clean up basically ugly
code that neither you nor others can easily understand. The important thing is
to have a good reason to rewrite besides "I always do it that way."

Always rewrite from scratch on principle? This is the path to madness,
failure, project overruns, and downright disasters. That is unless you are
very very lucky. Luck helps but good software is not produced by luck.

~~~
elviejo
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.

------
zepolen
I use this technique all the time, a quick throwaway prototype to get
something working and the basics figured out, then sit back think about how it
should be done properly and redo it bearing in mind the possible traps you
missed the first time.

------
leftnode
Yes, I entirely agree with doing this, especially if you get requirements
while you're working. In college, I was working on a site that I received
piecewise requirements, and one requirement would cause me to rewrite one
module that would cause conflicts with others. Once I was satisfied that I had
all of the requirements, I simply rewrote everything almost entirely from
scratch.

So yes, its best to try to write it correctly the first time, but its ok to
rewrite it a second. After that, you should probably look as to what you're
doing wrong.

------
s3b
I think its best to write once to get the tests done right and to make sure
the design works, then rewrite to get the code more readable. That way the
tests will save you if you screw up the rewrite.

------
lallysingh
IMHO there's some code that deserves more than 1 rewrite.

For example the library Powerplant (Metrowerks' mac equivalent to MFC) was
rewritten a dozen times before it was released, as its design patterns needed
a lot of fishing out to get them right.

