so, what's the problem of the code base business-wise?
"Business team have an aggressive road map" and "productivity is abysmally low".
Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
161–170 of 704 posts
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#162First off, no, a full rewrite is not only not necessary, but probably the worst possible approach. Do a piece at a time. You will eventually have re-written all the code, but do not ever fall into the trap of a "full re-write". It doesn't work. But before you re-write once line of code - get some testing in place. Or, a lot of testing. If you have end-to-end tests that run through every feature that is currently used…
Your suggestion sounds like the strangler fig pattern. While a valuable strategy in some cases, it does present the risk of duplicating poor architecture choices into the new code.
I would normally opt for your suggested approach too. However, based on the description given, I’d most likely recommend a complete rewrite in this case. The architecture appears to be quite poor and the risk of infecting new code with previous bad decision-making may be too great.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#163simonw's version control plan would be my step 1.
Step -2 is what you are doing now, OP, getting informed about the best way to go about this.
Step -1 is forming the battle plan of what you're going to change and in what order of importance.
Step 0 is communicating your plan to all stakeholders (owners, managers, devs, whoever) so they have an idea what is coming down the pipe. Here is where you assure them that you see this as a long process of continual improvement. Even though your end goal is to get to full VCS/CI/CD/DB Migrations/Monitoring, you're not trying to get there TODAY.
Step 1 is getting the codebase into a VCS. Get it in VCS with simonw's plan elsewhere in this thread. It doesn't have to be git if the team has another tool they want to put in place, but git is a decent default if you have no other preferences.
Step 2, for me, would be to make sure I had DB backups happening on a nightly basis. And, at least once, I'd want to verify that I could restore a nightly backup to a DB server somewhere (anywhere! Cloud/Laptop/On-prem)
Step 3, again, for me, would be to create an automatically-updated "dev" server. Basically create a complementary cronjob to simonw's auto-committer. This cronjob will simply clone the repo down to a brand new "dev" server. So changes will go: requirement -> developer's head -> production code change -> autocommit to github -> autoclone main branch to dev server.
Chances are nobody has any idea how to spin up the website on a new server. That's fine! Take this opportunity to document, in a `README.md` in your autocommitting codebase on the production server, the steps it takes to get the dev server running. Include as much detail as you can tolerate while still making progress. Don't worry about having a complete ansible playbook or anything. Just create a markdown list of steps you take as you take them. Things like `install PHP version X.Y via apt` or `modify DB firewall to allow dev server IP`.
Now you have 2 servers that are running identical code that can be modified independently of each other. Congratulations, you've reached dev-prod parity[1]!
Note that all of these changes can be done without impacting the production website or feature velocity or anyone's current workflow. This is the best way to introduce a team to the benefits of modern development practices. Don't foist your worldview upon them haphazardly. Start giving them capabilities they didn't have before, or taking away entire categories of problems they currently have, and let the desire build naturally.
There are a number of things you mentioned that I would recommend NOT changing, or at least, not until you're well down the road of having straightened this mess out. From your list:
> it runs on PHP The important part here is that it _runs_ on anything at all.
> it doesn't use any framework This can come much, much later, if it's ever really needed.
> no code has ever been deleted. As you make dev improvements, one day folks will wake up and realize that they're confident to delete code in ways they didn't used to be able to.
> no caching Cache as a solution of last-resort. If the current site is fast enough to do the job without caching, then don't worry about it.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#164You won't be able to fix it unless you get business to see it as a blocker. So that's the first task.
Second task is to come up with a plan to your refactor. Break it down with time estimates, etc.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#165Lots of people are giving advice on how to fix the code piecemeal. First put it on Git, then add tests, then, carefully and gradually, start fixing the issues. Depending on the project, this could take a year or several years, which isn't bad. The problem with this plan is corporate politics. Say that OP takes on this challenge. He makes a plan and carefully and patiently executes it. Say that in six months he's alre…
[deleted]
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#166No you don't need a full rewrite. You said it already: this code generates more than 20 million dollars a year of revenue (reality: it's probably not just the code generating that revenue).
You need to introduce things bit by bit to convince the team. Start with version control.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#1673 junior engineers are holding together legacy code that generates 20 mil a year having had no leadership that has taught them any sort of best practices? Give them all raises and get over yourself.
OP says it has been developed over the course of 12 years. The team is currently 3 junior devs. There's probably a huge turnover.
It's likely there's a lot of history and political shenanigans that OP isn't aware of yet. This could be a sinking ship. If it's a profitable business why is the team made of juniors?
A small company with legacy code that is a huge mess but that is maintained by the same person for the last 10 years is one thing. The same mess in the hands of 3 juniors who don't even use version control means no one with experience has lasted long enough at this company. That's a red flag.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#168First off, source control. I would say this was a day 1 job. Get some type of CI/devops thing going so you can deploy to a temporary test environment whenever you want. This applies to the data too so that means getting backups working. Don't forget email notifications and stuff like that. Next comes some manner of automated testing. Nothing too flash, just try to cover as much of the codebase as possible so you can…
Security could actually be a way to sell the need for cleanup. Hire a team of independent auditors. If the code is in such a bad state as you claim, i guarantee they will find at least a dozen of XSS and XSRF issues, very likely some SQL injections and possible even a few RCE as root.
Maybe not the best way to increase direct revenue if the product is working, but it highlights the risk they are taking with such a shaky foundation, and puts the decision on managements table rather than yours.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#169First off, no, a full rewrite is not only not necessary, but probably the worst possible approach. Do a piece at a time. You will eventually have re-written all the code, but do not ever fall into the trap of a "full re-write". It doesn't work. But before you re-write once line of code - get some testing in place. Or, a lot of testing. If you have end-to-end tests that run through every feature that is currently used…
Do it in small pieces and you'll be there forever - it'll never get done.
Map out the functionality related to the (hard) requirements and kick off replacing the product(s) with something modern and boring.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#170Earlier quoted context omitted.
Source control seems like a straightforward first step, regardless of what approach is going to be taken going forward
One would think, but how do you go from source control to deployment on the production server though? If they were editing files on the server directly, there could be a whole mess of symlinks and whatever else on there. Even worse, how do you even test things to see if you break anything? It is a can of worms.
Doesn't Git support symlinks? Empty directories could be trouble though. One would have to put a .GITKEEP into every directory before checkin, and a step at deployment time to remove them again.