Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

If the code generate 20 mio revenue, then it is very successful code. It might be ugly, but clearly something works right. You say "the mess is just too huge to be able to build anything" - nevertheless these three juniors have managed to build something with great business value. Most likely they are more productive as measured in revenue pr development effort, than most of the experts giving you advice in this comment section. The worst code is code which doesn't work or doesn't fulfill its purpose - regardless of how many patterns and best practices it implements.

The dirty secret in software development is most advice and "best practices" have no empirical basis. If "bad" code is highly successful, is it really bad? If theory does not match reality, is it reality that is wrong?

So before you try to change everything, you should eat a bit of humble-pie and try to understand how the code became successful in the first place. Otherwise you very easily throw the baby out with the bathwater.

For example:

> it doesn't use composer or any dependency management. It's all require_once

I'm not familiar with PHP patterns, but I would venture a guess that this "require_once" pattern is also the simplest? If you talk to real seasoned experts, they will harp on "keep it simple", while complex patterns are often being pushed by sophomores and consultants.

> no code has ever been deleted. Things are just added . I gather the reason for that is because it was developed on production directly and deleting things is too risky.

Perhaps, but this is actually reminiscent to the open/closed principle, part of the SOLID framework, which at least at one point was considered best practice: Improve code by adding and extending, not rewriting working code already in use.

> no MVC pattern of course, or whatever pattern.

Great! Patterns are an antipattern. Or slightly less flippant: Patterns are not a sign of quality or a goal in themselves. Patterns are solution to problems, so only appropriate if you have that problem in the first place.

Bottom line: You might learn a lot from working on this project.

> Resistance to change is huge.

I can understand that, if they have built something highly successful, and now you waltz in and declare that they are doing everything wrong because they are not using enough patterns.

You are right about source control though.

One of the hard things about what we're assuming is OP's tech lead role is that they're having to influence changes up (with management) and down/laterally (with the team). Things that might convince the team are going to be generally different than the things that might convince management. Management will probably be more convinced by things like improved lead time for changes, eliminating risk of failure, improving confidence in correctness of feature roll-out (though some of this depends a lot on the industry / domain and the incentives of management). Meanwhile the team will be more convinced by things like making their job easier or setting themselves up with more and better skills to take a "better" job down the road.

The rub with all this is that if the team doesn't like OP's changes (e.g., using source control), they'll have management cover right now. At each step it's important to show why it's better.

A way to do that—hard to tell if it's the right way without knowing more about the team's dynamics—is to make a lot of the changes for your own work. For example, set up your own test environment, develop there, then using this mystical "source control" magic apply the safely-tested changes to prod. Eventually someone will notice that you're not breaking prod as much as everyone else. ("You" here being either OP, or someone else in the same situation.)

All of this is just nuance, politics, and team dynamics layered on top of the excellent recommendation I'm replying to.

The physicist said that God must be a physicist, because He had to know about matter and energy and so on.

The engineer said that God must be an engineer, because He had to do something useful with the matter and energy - turning chaos into order.

And the business guy asked, "Where do you think all that chaos was coming from?"

No, seriously, some projects like this are lost causes. The company wants to just get maximal return on minimal effort. A rewrite is going to be a sunk cost with no return.

Basically, your job is to limp it along if you can't prove that a rewrite will make them more money.

If you don't like that answer, you might as well look elsewhere.