

Rewriting from scratch - callum85
https://gocardless.com/blog/starting-from-scratch/

======
mbesto
So I know re-writing a technical system from scratch is always consider a big
no-no. A couple of observations to counter that argument:

1\. Re-writing code is the Innovator's Solution to the Innovator's Dilemma.[0]

2\. Mozilla wouldn't exist today if the Netscape team didn't decide to rewrite
their browser engine.[1]

3\. Isn't Basecamp New a rewrite?[2]

[0][http://www.amazon.com/The-Innovators-Solution-Sustaining-
Suc...](http://www.amazon.com/The-Innovators-Solution-Sustaining-
Successful/dp/1578518520)
[1][http://en.wikipedia.org/wiki/Mozilla#History](http://en.wikipedia.org/wiki/Mozilla#History)
[2][http://basecamp.com/new](http://basecamp.com/new)

Thoughts?

~~~
lmm
1\. Without buying the book that sounds like a meaningless buzzword.

2\. Mozilla wouldn't exist today if the Netscape team didn't _destroy their
company_ by deciding to rewrite their browser engine, no.

Whether we'd be worse or better off is an open question - a living commercial
netscape could have kept the browser wars and associated innovation alive
longer. On the opensource side maybe the better-architectured KHTML would have
gathered more mindshare and funding and evolved into something like today's
WebKit faster without the distraction of gecko.

~~~
mbesto
> _that sounds like a meaningless buzzword._

I can assure you they are _not_ meaningless buzzwords. I'd recommend reading
the book before commenting since your reply adds nothing to the discussion.

> _2\. Mozilla wouldn 't exist today if the Netscape team didn't destroy their
> company_

Any source to back up the claim that the Netscape team maliciously destroyed
the company? What would be their motive? From everything I've read the
codebase was an absolute mess, hence the motivation for a re-write.

~~~
rwallace
The code being a mess usually calls for refactoring not rewriting. As I
understand it, the showstopper that made a rewrite necessary was that they had
made the mistake (understandable since they were in a desperate hurry but
mistake nonetheless) of using proprietary libraries.

~~~
13b9f227ecf0
Technical debt can accrue to the point where a piece of software is
"bankrupt." Any successful refactoring amounts to extracting a subset and
redoing everything else, which can practically amount to a rewrite.

------
_pmf_
> Our old dashboards were at a local maximum, making it hard to iterate.
> Introducing elements of a variable Direct Debit interface would have added
> complexity, with no benefit until the whole new interface was ready.

> For a fundamental change in UI that lack of iteration wasn't acceptable.
> Starting from scratch with an early beta let us to collect feedback on the
> new interface immediately. Our speed of iteration was also increased as we
> didn't have to worry about breaking an existing interface.

I would have said "I've created an unmaintainable mess.", but from now on,
I'll be using your nice euphemisms. "Local maximum" ... yeah, sounds proactive
and empowering. I'll have to work on delivering it with a straight face,
though.

------
txutxu
In my opinion, It's ok to rewrite, if you finish, on time, and it works as
expected.

You can see all kind of "rewrites" some with more luck, and others with worse.
This one seems successful (I talk without numbers).

I've a personal pet project I'm always rewriting (from scratch). But, it's the
single project in my life I can't validate the result, I've try many
approaches. There is a few corner cases, were the only exit is to use unclean
workarounds by language limitation... and even after a few renames and even
language evolution, I think I'll retire "still rewriting from scratch" if I
feel it can be better, and I've the freedom/budget/time to do it.

------
beat
Consider the Big Ball of Mud:
[http://www.laputan.org/mud/](http://www.laputan.org/mud/)

This can be either a pattern or an antipattern, depending on your perspective.
I tend to think of it as an antipattern. Rewrites are often driven by
difficulty in refactoring more than fundamental flaws, but the refactoring
problems are caused by coupling between layers/systems.

The problem with rewriting to avoid a refactoring is that you're most likely
going to wind up with a shiny new Ball of Mud.

------
ninjakeyboard
There is a huge body of experience out there that does state this is insane
and generally crashes and burns and fails horribly. Good on ya to go against
the odds and win.

------
Siecje
In the article you didn't need to do a re-write of the entire site, just a re-
design of the UI.

You needed to add functionality but you could have left the old working
functionality.

Another case for a re-right is when the project uses old technology that is
hard to maintain with the people you have.

Re-writing the system in a framework that your team understands will take less
time than trying to understand another framework.

