

To rewrite the code or not? - run4fun

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).<p>I took a look at the codebase today, and (at least to me) it seems incredibly messy.<p>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?<p>I think I could do the whole thing myself in a couple days, so it wouldn't be a HUGE deal.<p>Your opinions much appreciated. Thanks.
======
kogir
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.

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

------
npk
Likely not:

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

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

------
mellampudi
"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.

------
aantix
<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!"

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

~~~
rob
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.

~~~
jamongkad
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.

------
mynameishere
_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?

~~~
wensing
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?

------
socmoth
beware the great rewrite.

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

