5

I have an old codebase that still "works" but is difficult/nearly impossible to maintain. It may be expensive (time and money wise) to update it. Do I just go for it, or should I continue to hate my world (but continue working on something that works and is relatively bug-free)?

Improve this question
2
  • What language is the codebase?
    – adamcodes
    Jul 8, 2010 at 19:52
  • Without specifics of the site, I think this is not a real question, and I've voted to close as such.
    – delete
    Jul 16, 2010 at 7:14

4 Answers 4

Reset to default
5

If you see a future in your site please rewrite it as soon as posible if it's not maintainable. I maintain several +5 year old big sites and in the time I've spend cursing on the stupid problems that came from it I could have rewritten them all. Do yourself a pleasure and rewrite it, it's more fun to build something new as well ;)

Improve this answer
1
  • Ah yes, all those wasted hours swearing. It makes you feel so much better at the time, though...
    – Bryson
    Jul 16, 2010 at 7:07
1

I'm sure it depends on the specific circumstances, but be sure to factor in the extra time you have to spend maintaining your existing codebase vs. the expense of updating it. Not knowing more details, I'd say update it rather than struggling with what you've got.

Improve this answer
1

I agree with @D4V360, there is indeed pleasure in writing something anew. Also, consider the concept of "Technical Debt" that Jeff and Joel have spoken about in their podcasts. Here are some pertinent links on the subject:

  • Steve McConnell (author of the great book "Code Compete") on Technical Debt
  • The aforementioned and our very own Jeff Atwood on Technical Debt
Improve this answer
0

I am in a similar situation. My company has their legacy website that does everything they need. In addition, they have a website being built by an outside company to replace it that does 90% of what they need. They expect that 90% to become 110%.

I have decided on the following course of action:

  • Maintain the legacy website until the new site is delivered
  • Get the extra features integrated into the new site as quickly as possible
  • Maintain the new website as if it were not being replaced
  • Once everything is up and running, rebuild the site and create a migration plan
  • Migrate to the new new site and forget that either of those old ones ever existed

As much as I'd like to simply ignore the other two sites, that's not an option. Regardless of how I feel about it, the site that is being delivered will have to serve us for a certain number of months before I can even attempt to replace it. Optimizing, maintaining, and improving upon it will be my priority. That site must perform during its lifetime. So building the new new site will be a during-those-times-that-everything-is-working and on-my-personal-time-when-I-want-to-hack-on-something project. But that's fine, since it manages everybody's expectations. The company that expects this new site to perform to a certain level will have their site performing at that level, and at the same time I'll be actively improving it behind the scenes. And at the same time again, I will be building a replacement that will blow it away.

In my situation, my "new site" (from the outside company) is your legacy codebase, and my "new new site" is your should-I-just-rebuild-it. So I guess my short answer is that while maintaining the legacy codebase to keep the world turning, you can still rebuild.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.