Ask HN: When does it make sense to complete rebuild a web application?
5 comments
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.
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.
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.
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?
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?
Would need to see the git repo. I could only find this 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.
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.
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.
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.
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.
On the other hand, this software is widely used and deployed at different locations. It's not terrible but also not a great experience using it.
Would you rebuild the project from scratch? How would you go about it? Would you use a web framework?
(Mentioned software is Stud.IP, a campus management system and e-learning platform for German universities)