0

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?

Improve this question
1
  • My personal opinion, from experience, is to never, never do a rewrite. Make adjustment where possible, refactor along the way so that all the new stuff you are adding is better structured, but do not start a big rewrite; history is full of projects that died because someone decided that the best thing was to throw away everything and start from scratch, too much is lost. Commented Jan 13, 2021 at 13:37

2 Answers 2

Reset to default
1

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

Improve this answer
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.