
Ask HN: When does it make sense to complete rebuild a web application? - nanope
This open source application is built on the same PHP codebase that existed since 2001. Over time it developed for example a custom MVC framework, a templating engine, ORM and object serializer.<p>On one hand it is very hard to get new developers on board, since there is no good documentation and there were questionable decisions in designing this application.<p>On the other hand, this software is widely used and deployed at different locations. It&#x27;s not terrible but also not a great experience using it.<p>Would you rebuild the project from scratch? How would you go about it? Would you use a web framework?<p>(Mentioned software is Stud.IP, a campus management system and e-learning platform for German universities)
======
PragmaticPulp
Rarely.

Complete rewrites invariably take far longer than expected. That old codebase,
however messy, includes almost two decades of decisions, lessons learned,
special cases, and tribal knowledge. The rewrite will surface each one of
those issues again over time.

Second, you need to retrain everyone on the new software. Surely the new UI/UX
will be better, but how many people have years of accumulated knowledge in the
old software? It's not just about retraining. Some of the old users will hate
the new system just because they don't like change. It may be objectively
better, but if it makes everyone complain to your boss's boss every day
because 100 people had to relearn a new system, is it really better for the
org?

Third, the old software is certainly more complex than you can see from the
surface. At minimum, you should start by adding analytics to the existing
codebase so you can see which features are used. You will be surprised to
learn that people use the software much differently than you would have
guessed.

Fourth, you're not off the hook for maintaining and supporting the old
software during the rewrite. If a new, urgent feature request comes in and the
rewrite is too far behind schedule to be ready in time (it will be behind
schedule, guaranteed) then you must still service the old codebase in the
interim. This is a constant tax on productivity that slows down rewrites,
unless you can justify two completely independent teams.

My advice: Make an effort to calculate the ROI on the rewrite. Include the
overhead of maintaining the current system during the rewrite, as well as the
costs of retraining everyone who used the old software. If you can't reduce
overall costs after a few years with a rewrite, it's hard to justify. It's an
unpopular opinion with programmers, but some times it really does make sense
to continue to throw developers at an old codebase instead of rewriting from
scratch.

If you must rewrite, look for a way to rewrite incrementally. For example,
writing a new front-end for the existing back-end with a modular API
translation layer. Ship the new front-end, work out the bugs, and then work on
replacing the back-end later. Depending on the codebase, you may even be able
to write a backend shim and slowly replace individual endpoints and rework the
API one feature at a time until the old backend can be fully deprecated.

------
codingdave
I see no reason for a rewrite based on those problems. You have a codebase
that has been working for 18 years, and still works. The problems you
described are with maintaining it, and usability, but not with its
functionality.

There is no documentation, so write some. Question decisions were made, so do
(major) refactors to correct those decisions. Likewise, you can pick pieces to
modernize, one at a time, and improve the UX one piece at a time.

This does sound like a sizable project to get it where you want, and if you do
one piece at a time, you may end up with 90+% new code when all is said and
done anyway... but you'll do it in bite size pieces without impacting your
customers or your stability.

------
thijsvandien
The infamous rewrites that Joel Spolsky once urged to never do, are those
where development on the current version is halted while a brand new version
is developed from scratch and then launched with a big bang. Without answering
the question directly, web applications are some of the easiest to rewrite
gradually, endpoint by endpoint. Especially in PHP, where requests are
stateless. You could start a new thing in the middle of the old thing and
slowly let it take over, while already live and working in tandem with the old
parts.

------
saluki
I would consider a rewrite, if anything else for security, has the existing
code base been updated to run on PHP 7.3?

I would look at using the Laravel framework for the rewrite.

This would also offload maintaining the existing framework, templating and
ORM. Plus you'll gain lots of features already in the Laravel framework that
the legacy framework probably does not have.

Does the app have modules or components that you could start moving over to
Laravel one by one?

------
1ba9115454
Would need to see the git repo. I could only find this
[https://github.com/studip/studip-gsoc2013](https://github.com/studip/studip-
gsoc2013)

If this is an example of the code base then it doens't look too bad in terms
of layout.

BUT before a re-write/refactor.

Get a really good CI/CD process in place. i.e. build -> unit test -> browser
testing.

