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? http://www.joelonsoftware.com/articles/fog0000000069.html

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.

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?

[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.

[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 → alex_c]

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.

[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 → Zak]

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.