Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've inherited a project that's accrued, layer upon layer, like a pearl over the last six years. It started out as a web page to let the client check the status of their work in production, and has become a full-fledged shopping cart system with a variety of domain-specific features, which involve visualizing custom graphics. Nothing hugely challenging, though with many elements rather particular to this client.

The issue is that the code is super crufty, which is not surprising considering its heritage: it's like a giant ball of duct tape at this point, the database schema included; and it's really hard to wrap your head around the thing for this reason, and also because the developers who were in charge of it for the past six years weren't web developers and kind of made it all up as they went.

Anyway, the system is successful and useful, and the client likes it, to the point that they regularly want new stuff added to it. But it's really hard to add new stuff to it because it's brittle, and I have been increasingly inclined to scrap all new development on the old codebase and rewrite the thing in Rails (it's all custom PHP at the moment.) The question is, should I?

Reasons against:

  • It's always way more work re-designing an application than you think it will be
  • Especially when you're re-doing it in a different language and different framework
  • Maintaining two code bases (for a while) will be extra work
  • It might be better to incrementally rewrite, keeping it in PHP, and redesigning as we go

Reasons for:

  • At this point adding new features requires tearing the thing apart and trying to figure out what I broke. A redesign would pay for itself in short order, when this process became more regular and less chaotic

  • The client's needs have changed substantially in the last six years, and it would be good to have them reflected from the beginning in the architecture

  • Going to a popular and widely-supported and well-understood framework will give us the luxury of not reinventing the wheel for every part of the system, and allow us to use high-quality components other people have made

Anyway, you get the point. I alternate between what I think the right thing to do is. I've developed a good relationship with the client and they trust me, so they'll probably do what I recommend. Does anyone who's been here before have any advice?

share|improve this question
add comment

2 Answers

If you have the vision and the courage to re-write the project, then go ahead and do it, however...

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

share|improve this answer
add comment

I was in the exact same situation that you're in right now. It became clear to me that the kinds of changes they wanted were not going to fit into the existing system, so I looked at possibilities and eventually proposed that it might be worthwhile to have me redevelop or refactor the whole system to allow for these kinds of changes. The CoO took it up with the President. About eight months later they purchased a commercial solution without any technical consulting that did less than the existing system and required more effort to support and still couldn't do the things they wanted.

So, beware of what you say about needing to replace existing system. Use words like "refactor" instead of "replace".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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