On code quality: rewrite once(blog.tetrack.com)
blog.tetrack.com
On code quality: rewrite once
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.
7 comments
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?
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?
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.
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.
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.
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.
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...
You are right. Refactoring can be "the way" to improve existing code. This technique is meant to improve the quality of the first implementation. Think about the first source control submit.
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.
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.
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.
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.
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.)
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.)
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.
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.
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.
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.
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.
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.