

Ask News.YC: Should you rewrite your software from scratch? - palish

The decision to rewrite software has hurt some companies.  However, we only hear about the bad that's come from a software rewrite, never the good.  So with today's new coding methods, do articles like this one still apply?  <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000069.html</a><p>Have any of you rewritten or made the decision to rewrite a large codebase?  I know Kiko mentioned it as one of the things that hurt them.  Microsoft was about to do it with their Pyramid Project, but it was axed.<p>Another question, for YC: Do YC companies generally rewrite their projects after Demo Day (since it's supposed to be a throwaway prototype), or work with what they've got?
======
alex_c
During high school some people wrote drafts of assignments and then made a
"good copy" to hand in (it was high school, so busywork was common, I guess?)
A teacher warned us that this is not going to work in university.

True enough, in university I quickly learned to get things right the first
time - because I won't have time for a second try. It's a habit I've kept
after I graduated.

I think the parallel to software is pretty obvious. It's easy to say "I'll
rewrite this later", but when later rolls around, you have 3 other deadlines
to meet. Throw-away code might still stay in the production code for 2 years.
Refactoring parts of the code is good and necessary, but there are only so
many resources you can dedicate to it.

I guess if you're seriously considering rewriting something from scratch,
you're already caught between a rock and a hard place. Rewrite, and you miss
an entire development cycle at least - time that could be spent enhancing or
adding features. Stick with what you have, and you have to work with a
codebase that makes development a nightmare (otherwise you wouldn't consider
rewriting).

Better to avoid it if possible - do a bit of planning upfront, refactor when
you can, have enough tests that refactoring is safe.

At my last job we rewrote a large part of the application - but it was done
piecemeal, over two years, and never halted development or delayed new
features. Refactoring was "snuck in" as part of deliverables whenever it was
possible and safe. It was worth it because the new code performed up to 2
orders of magnitude better, and was much easier to work with - but we never
would've been able to do it if we simply decided to drop everything and
announce that we're rewriting the app from scratch.

~~~
Jd
Your technique might get you through college fine, but to become a truly great
writer one must write and rewrite, not because anyone demands it of you, but
simply because one cannot imagine it any other way. Same goes for other
artistic forms.

------
msiegel
In one ongoing series of consumer products, my several-hundred-thousand-line
codebase lasted for well over 10 years. There was no reason to mess with it.
Yes, I thought parts were messy... but there was also great stuff in it that
I'm very happy survived intact.

Then decades later, on an entirely different product, in a different
business...

We had to migrate our product to a new OS platform, as well as needing to
fulfill much wider requirements for our customers. The existing code just
wouldn't allow this, even if it were stretched and stretched.

So I rewrote most of the codebase.

In some ways I was tortured knowing we had a functioning product that already
handled things I was rewriting (even though it was on an obsolete platform).
Especially since the rewriting process takes longer than _zero_.

On the other hand, the new set of code turned out smaller, simpler, more
reliable, much more flexible, and is now working well as a foundation our for
business.

Both sides of the argument make sense to me, I think it just depends on the
situation.

------
sanj
Writing "one to throw away" is an excellent idea. You'll figure out the hard
parts of the problem and if it has a chance of succeeding. This is what a
startup should do post demo-day.

Throwing away something that's been tuned to target customers is a mistake.
This is what Joel is talking about.

Most importantly, these are very, very different activities.

Except, of course, when time and money is ticking and they're not. Then you
have to brave (which is what you call it when it works) or foolish (which is
what you call it when it doesn't).

------
mark-t
I completely agree with Joel. I've done major refactoring work by making a
series of minor alterations that clearly don't change anything. This approach
takes a lot less time and doesn't introduce nearly as many bugs. Our svn
repository is at revision 4995, and that's forked from a project that's 4
years older. Imagine how many of those commits have been bug fixes, and you'll
see the big problem with rewriting.

------
Zak
reddit did, with good results.

I think if you don't have a good idea of what you're doing when you start, you
might need to write a throwaway version first, see what works and what
doesn't, then write the real app. I suspect in many cases, bottom-up design
will reduce the need to rewrite by giving you more opportunities to refactor
instead of throwing out the whole thing.

~~~
palish
I believe they also rewrote again just recently, and that's why Reddit hasn't
seen new features for awhile. But perhaps they can afford it since they've
been acquired.

------
Goladus
I think sometimes a rewrite is worthwhile, but basically Joel's advice is
good. Don't just do a rewrite with this vague idea that you'll be able to do
it right this time.

