

On starting over. Don't do it. - kentf
http://www.ewakened.com/2012/03/on-starting-over/

======
dissident
Where's the reasoning for this? Frequently starting over is a problem, but
code refactoring can have immense benefits. Discovering a different framework
or language may suit your work better, for instance.

Monkeypiling on top of old work is really advice out of the 90's.

These articles with a bunch of three word sentences and zero justification are
becoming annoying.

~~~
paulhauggis
Sometimes, it's just not a good idea. If you have a piece of software that has
been battle tested and many of the bugs have been worked out over the course
of several years, you will have an entire new set of bugs with a complete re-
write (which could take lots of time to figure out).

I've also seen this as a solution to many problems because it was much easier
for the developer to start over than to figure out the existing code and try
to work with it.

But, there are some instances when a rewrite is the answer.

------
AlexCP
I have to disagree, sometimes it is a lot better to start over. For example,
with legacy code with bad test or even worse, with no test at all.

~~~
Splognosticus
If your legacy code has no tests, how do you know its replacement works
correctly?

~~~
bunderbunder
If your legacy code has no tests, how do you know it works correctly?

~~~
kennu
Because it's in production and people are using it. When you rewrite a new
implementation from scratch and deploy it, you make their lives miserable,
because so many things will break. This is nearly inevitable.

When talking about websites and web applications, client-side integration
makes it nowadays very easy to add new modules to legacy codebases using a
completely different technology. With a little bit of JavaScript, you can have
some parts of webpages coming from an entirely different new server, using a
new fresh framework and backend database. I think this is the best way to
start migrating to new technologies, one step at a time.

~~~
bunderbunder
_Because it's in production and people are using it._

I've run into more examples of broken code for which the above statement is
true than I care to remember.

My original response was meant to be a rhetorical question, with the purpose
of hinting that techniques for verifying the correctness of code might have
existed existed prior to the 1990s. But "we haven't heard any complaints from
users yet," while certainly a popular technique, is only slightly more
reliable than prayer as a QA policy and I personally wouldn't recommend
relying on it.

~~~
Splognosticus
That's kind of the angle I was coming from as well. In order to effectively
rewrite something you first need to know what the existing code _actually_
does. If you don't know that yet, then figuring it out is usually a lot harder
than fixing whatever problems it has.

It's not that you should never rewrite, but it's always a lot more work than
you think it's going to be.

