When approaching seemingly insurmountable technical issues, I've found it important to find the root issue of what's causing all the chaos. Yes, the code is a mess. OK, the database design is non-sensical. Sure, things never get deleted. But why?
From what you've mentioned, it sounds like every change that isn't additive is viewed as too risky. So at this point before trying to make big shifts, some work should be done to de-risk the situation as much as possible. Granted, you probably can't stop work and introduce a bunch of new practices and patterns, but you need to start reduce the risk to unleash the team to make necessary changes.
For example, introducing version control should be a slam dunk. Start using a database migration facility for all database changes. Create a release schedule that requires features to be stabilized by a certain window for deployment. Create some really, really simple Selenium tests by just browser recording yourself using the app.
Once you can start making changes more confidently, then you can start unwinding some of the bad choices moving forward. Resist the urge to start "making a good foundation for the future" by trying to rewrite core parts of the system immediately and instead start thinking in terms of forward progress oriented changes. Need to add a feature? Make sure to write that feature properly with good practices and make only the necessary changes to other parts of the system. I realize that's probably going to be painful, but eventually you will accrete enough of these small changes that you can string them together with a little more work into larger scale changes under the hood.
These things are rarely easy, especially in established legacy systems. But if this is the revenue engine for your company, you'll need to move conservatively but decisively or risk making the situation worse. Good luck!
This is really good advice. Thanks for sharing this. I think you've probably nailed it on the head about trying to find the reason and it likely being because people are too afraid of the risk of messing stuff up, so they keep adding to the ball of mud.
However, in my experience, it can be very touch and go dealing with people who become so risk averse. I had a job one time where a previous employee refused to give up a computer that had to be at least 10-15 years old at the time (was running Windows 2000 or something like that) and took about 30 minutes to boot up. Because somehow it was the only computer that could run the 3D CAD program he was familiar with or some other "reasons" that it was essential to the project. The only way of moving forward was that he luckily completely washed his hands of the project before I even joined the company, and then I did a full rewrite and redesign of the whole system from scratch (which was absolutely required in that case). Even then, when I asked him about the computer to just be careful and do due diligence to try and figure out why or if it was actually important, he was very resistant of me sending the computer to the salvage department after getting the files off the computer.
From what you've mentioned, it sounds like every change that isn't additive is viewed as too risky. So at this point before trying to make big shifts, some work should be done to de-risk the situation as much as possible. Granted, you probably can't stop work and introduce a bunch of new practices and patterns, but you need to start reduce the risk to unleash the team to make necessary changes.
For example, introducing version control should be a slam dunk. Start using a database migration facility for all database changes. Create a release schedule that requires features to be stabilized by a certain window for deployment. Create some really, really simple Selenium tests by just browser recording yourself using the app.
Once you can start making changes more confidently, then you can start unwinding some of the bad choices moving forward. Resist the urge to start "making a good foundation for the future" by trying to rewrite core parts of the system immediately and instead start thinking in terms of forward progress oriented changes. Need to add a feature? Make sure to write that feature properly with good practices and make only the necessary changes to other parts of the system. I realize that's probably going to be painful, but eventually you will accrete enough of these small changes that you can string them together with a little more work into larger scale changes under the hood.
These things are rarely easy, especially in established legacy systems. But if this is the revenue engine for your company, you'll need to move conservatively but decisively or risk making the situation worse. Good luck!