To rewrite the code or not? | Hacker News Reader

To rewrite the code or not?

7 pointsrun4fun13 comments

So I got an offer to join a cool new startup today. The founders have been developing the site in PHP using a framework the founder cooked up himself (not a full-fledged MVC job like Symphony or Rails, though).

I took a look at the codebase today, and (at least to me) it seems incredibly messy.

Am I too accustomed to working in a Rails-like environment or should I seriously suggest that we rewrite all the code in Symphony or Rails?

I think I could do the whole thing myself in a couple days, so it wouldn't be a HUGE deal.

Your opinions much appreciated. Thanks.

View on HN

I've learned a lot over the 2.5 years since starting Loopt and I feel that same way about much of my old code. I've found that rewrites can be a huge waste of time unless some key criteria are met:

1) The code is broken. If it's broken, a rewrite is preferable to an involved patch. What constitutes "involved" depends on time constraints and personal taste.

2) I'm about to build on top of the old code. If I'm going to extend or build on top of something I know is crap, I'll rewrite it (time permitting). Fixing it later will be substantially harder the more it's used, so it's best to fix it now.

I've also become more restrictive in what I consider bad code. Bad architecture and interface design are killer. It's nearly impossible to write something good on top of a crappy framework.

For example, if a method body sucks, but the parameters and return type are fine, I'll leave it be. The implementation can be rewritten later if needed.

However, if when writing some new code I find myself using a bunch of switch statements when the strategy pattern is more appropriate, I'll fix it immediately. It's infinitely easier to fix such things when you're adding the third concrete strategy than the sixth.

Also, on a completely unrelated note, if you can implement everything they've done "in a couple days," you'd better be getting founder equity. Furthermore, if the code really is bad and they won't acknowledge it, I'd high tail it out of there. You'll be fighting a constant battle because new code won't be any better.

Instead of a rewrite, how about working constructively to improve the existing code base, including the home cooked framework?

As with all startups, it's more important to release something - anything - (well ok, not anything!) than to produce perfect code.

Likely not:

http://www.joelonsoftware.com/articles/fog0000000069.html

They're not going to look on the idea favorably, and you risk pissing this guy off by telling him his code sucks.

I have basically sworn off PHP-using companies, because this is nearly always what you find. It works, but it's a horrid mess that they expect you to develop with rapidly, when all you want to do is take it outside and burn it.

"I think I could do the whole thing myself in a couple days, so it wouldn't be a HUGE deal." If you really think so, do it without telling it to them on some weekend or when you have time and show it to them.

<scratching head>A rewrite in two days? Hmmm, either its not much of a product in terms of complexity or you are gravely underestimating the effort. I would guess the latter.

You must be prudent in this situation; any sort of rewrite/refactoring will not show visual progress with the product, so while things may be getting better on your end everyone else thinks that the development is stagnating.

Always be weary of actions where the end user won't see results. Refactor on the fly as best you can. Nobody will care (except for you) when you emerge from your cave a few months later and proclaim "The code is nice and clean; now we can proceed!"

If you feel like rewriting in Rails, make sure you consider the deployment factor.

In my experience, the only way to have a Rails app that is responsive and reliable without spending most of your time on deployment as opposed to on development, is having someone like EngineYard host it. But that costs 100s of dollars per month, which might be ok in your case, I don't know.

Maybe you want to go with Symphony instead.

I'm not so much against big rewrites, you just have to figure it out yourself if you think it makes sense.

I've been playing around with Symfony lately and I am very impressed with it. At first, the endless amount of directories seems to not make sense, but once you start to use it you'll see they make perfect sense.

Very easy to deploy as well given that it's written in PHP.

Why don't you try Code Igniter out? I fell in love with PHP again cuz of it. Plus it's pretty lightweight and snappy compared to Symfony. Not to mention they are pretty much similar in structure.

should I seriously suggest that we rewrite all the code

Great idea. And ask them about their severence benefits when you do this.

cool new startup ... I think I could do the whole thing myself in a couple days

How cool could it be if their technology is so simple?

How long do you think it would take to re-write the early version of most startup sites? Most of them aren't doing things that are inherently difficult, but rather new/unique/interesting/right-place-right-time. Twitter?

beware the great rewrite.

So let's see, the question is whether or not you should spend two days doing _something_ to the code that will make your ownership of it easier to manage?

Sounds like a no-brainer. Go for it. Of course, you'd better be sure you can really pull it off in a couple of days. Programmers are notorious for under-estimating these things. But in general, if you're going to be doing something for 2 months or more and you can do something up front that saves you ten percent or so -- do the math. Don't get into "always rewrite" or "never rewrite"

If you can recreate what they're doing that quickly, you're not that far along the development path anyway. There's a whole different answer if they've spent 3 months plugging away at it and already have paying customers. But it doesn't sound like you are there.

Reply on news.ycombinator.com