4 ms·
Got hired into a project like this. The most critical part is not to emotionally loose your devs. So, they explained us their whole application and we set goals
by pabe 4y ago
Got hired into a project like this. The most critical part is not to emotionally loose your devs. So, they explained us their whole application and we set goals together. I tried to let them see their application from the eyes of a new customer. We identified performance & UX as the most pressing problems. A web service layer was added to the old application, we rewrote the whole frontend utilizing a modern framework. That way we got management excited ("wow, it's so beautiful now") and kept the original developers happy and engaged ("we're doing all the important logic & persistence here!").
We also introduced git as well as dev and staging tiers and some agile methodologies. Definitely do some that first!
Now, as management and customers are happy, the backend can be refactored step by step. Here, more test coverage might come in handy.
So, I'd recommend to be a bit picky about where to create value. You can restructure the whole database and that'll be good for maintenance (and most likely performance) but management & customers won't literally "see" much. Ask the people with the money for their preferences, excite them to get more runway. Regarding "backend stuff": Think like a Microservice architect and identify components that are least strongly coupled and have a big (performance) impact. Work on those when management is happy and you've got plenty of budget.
Your job is to create value and reduce risk. Not to create something that's technically awesome ;)