Thank you for so many suggestions. The main issue is productivity within a context where the company is trying to reinvent itself in terms of marketing and business model. This has for consequence that many new big features are being requested and promised by management to headquarters. But in the last years, all bug evolutions have been failures. That's why I've been asked to intervene.
I love the idea of the strangler pattern associated with big unit testing coverage.
> This has for consequence that many new big features are being requested and promised by management to headquarters. But in the last years, all bug evolutions have been failures. That's why I've been asked to intervene. I love the idea of the strangler pattern associated with big unit testing coverage.
The first thing that needs to be strangled is unachievable management promises. Figure out how to get local management to not write checks the tiny team can't cash. A team of 3 juniors will likely overestimate their ability to deliver, so you've probably got to teach them to say no to things they can't do also.
What you are dealing with is organically grown software. No one really understands it, and it's likely to be fragile.
I agree with all those here that say the first thing to do is to introduce version control. You don't want to break that money machine without a way to revert.
Second, introduce some lightweight form of code review, but don't tick people off.
Third, if you want to do something like revise the user interface, consider adding an API to the existing organic code base, and build the new UI with that API. Generally, take that approach and avoid jamming something into the middle of the existing code that no one fully understands.
I agree with this. I built an open source package that should work for you in this situation with no version control in it. https://github.com/n0nag0n/commie2 Get this installed internally and then start doing some "lightweight" code reviews. Your other team members can get emails about any comments you make and it'll be lightweight collaboration.
I had the chance to work with Strangler Pattern in multiple projects, and in general this is a good idea.
The thing I'd suggest taking a look at is the database. You really need to make sure the new part is not based on the old data model.
You can take a look at "getting started with DDD when surrounded by legacy systems" by Eric Evans - available for free and only 21 pages long. Our implementation of one of the suggested approaches failed in one project, but in retrospective, I think it was caused by the business not putting enough effort into the rewrite.
In general, on the high level it's very important to make the product vision, data model, processes clear and well thought. Without this, you will always get to a bad codebase within a couple of years.
