A lovely knot to unravel! First, get everything in source control! Next, make it possible to spin service up locally, pointing at production DB. Then, get the db running locally. Then get another server and get cd to that server, including creating the db, schema, and sample data. Then add tests, run on pr, then code review, then auto deploy to new server. This should stop the bleeding… no more index-new_2021-test-jo…
I largely agree with this approach, but with 2 important changes: 1) "Next, make it possible to spin service up locally, pointing at production DB." Do this, but NOT pointing at production DB. Why? You don't know if just spinning up the service causes updates to the database. And if it does, you don't want to risk corruption of production DB. This is too risky. Instead, make a COPY of the production DB and spin up lo…
Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
471–480 of 704 posts
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#472Earlier quoted context omitted.
You don't need comprehensive tests for tests to start delivering value. Figure out the single most important flow in the application - user registration and checkout in an e-commerce app, for example. Write an automated end-to-end test for that. You could go with full browser automation using something like Playwright, or you could use code that exercises HTTP endpoints without browser automation. Either is fine. Get…
You're assuming the existing flow is working perfectly and I agree with you that testing is a godsend. I constantly yell that testing is great. Heck, I even worked for Pivotal Labs that does TDD and pair development, and loved it. Let's say you start to write tests and start to see issues crop up. Now what? How do you fix those things? Github actions!? They don't even have source control to begin with. There are so m…
Right: no point in adding any tests until you've got source control in place. Hence my suggestion for a shortcut to doing that here: https://news.ycombinator.com/item?id=32884305
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#473Here's a way to introduce version control without having to stop everyone and teach them how to use it first: 1. Commit the entire production codebase to git and push it to a host (GitHub would be easiest here) 2. Set up a cron that runs once every ten minutes and commits ALL changes (with a dummy commit message) and pushes the result Now you have a repo that's capturing changes. If someone messes up you have a chanc…
Git on his own machine would be easiest. There is no need to consider a git host that the others can access until things are at the point where the others are ready to use git.
Even when they reach that point I question whether GitHub is the way to go. He didn't say much about their IT department but they have web servers and databases so evidently have people who can manage such things. It would be close to trivial for those people to set up git hosting on one of their own servers.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#474First of all: PHP is fine. It really is. Second: Doing a full rewrite with a junior team is not going to end well. They’ll just make other mistakes in the rewritten app, and then you’ll be back where your started. You need to gradually introduce better engineering practices, while at the same time keeping the project up and running (i.e. meeting business needs). I’d start with introducing revision control (git), then…
I would think about that very long. Over the years, experience has shown me that regardless of what framework or library you use, you introduce a lot of dependencies to your app when you build on such a framework or library. The common sense says that they should make things easier, and at the start they definitely do that. But over the years, you start encountering backwards-incompatible changes, major moves etc in those frameworks and libraries which start taking your time. And sometimes a considerable chunk.
I would only use a framework or library that has a major backwards compatibility policy or viewpoint. JSON's 'only add, never deprecate' is a very good ideal to strive to. Even if this couldn't be entirely feasible in software, it should be at least strived to.
So I'd say if something that is built in-house works, easy to use and keep maintained, there is absolutely no reason to move to an external framework.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#475You have to convince them that not only is this situation a drag reducing their future revenue, as they cannot develop it further with any speed, but it can also come crashing down catastrophically at any point in time.
It also sounds like the current team is not up for it you need more people and a dedicated project
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#476First 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…
> It doesn't work. That's simply not true. I've inherited something just as bad as this. We did a full rewrite and it was quite successful and the company went on to triple the revenue. > get some testing in place Writing tests for something that is already not functional, will be a waste of time. How do you fix the things that the test prove are broken? It is better to spend the time figuring out what all the featur…
There is a lot of evidence rewrites are hard to do well, and especially prone to failure.
…you might pull it off, it’s not impossible, sure. …but are you seriously saying it’s the approach everyone should take because it worked for you once?
Here my $0.02 meaningless anecdotal evidence: I’ve done a rewrite twice and it was a disaster once and went fine the second time. 50% strike rate, for me, personally, on a team of 8.
What’s your rate? How big was your team, how big was the project? What was the budget? Did you do it on time and on budget? It’s pretty easy to say, oh yeah, I rewrote some piece of crap that was a few hundred lines in my spare time.
…but the OP is dealing with a poorly documented system that’s very big, and very important and basically working fine. You’re dishing out bad advice here, because you happened to get lucky once.
Poor form.
Good advice: play it safe, use boring technology and migrate things piece by piece.
Big, high risk high reward plays are for things you do when a) things are on fire, or b) the cost of failure is very low, or c) you’re prepared to walk away and get a new job when they don’t work out.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#477Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#478Earlier quoted context omitted.
Before anything else, getting buy-in for any kind of major change from the execs is key. Explain the situation and the effects. Have everything in writing, complete with date and signatures. Push back hard every time this commitment gets sabotaged because something is supposedly on fire. Get a guaranteed budget for external trainings and workshops, again in writing. Then talk to the team. If you cannot get those comm…
To be fair if I was an exec at a company and the new IT lead wants me to commit, in writing, to XYZ, I’d not keep them around long. You can’t run a company on that kind of deep mistrust. Nothing in the OP suggests abusive management. Incompetence, maybe, but I see no reason to assume that they’ll backtrack on agreements, and a new management hire who immediately starts sewing mistrusts is not someone I’d trust to get…
Trust has to be earned in some ways (but you can expect some base-level). But I want to argue on another point: as an exec, you can use this kind of writing to also get commitment from the team, to balance things out. But ofc for that there needs to be a fair discussion of priorities and once you have that, there is usually no reason to contractify the outcome.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#479Your comment about productivity of the dev team is a red flag for me. They’re charged with containing this 20m revenue engine, it probably stresses them out big time. This is not the time to count feature development. When you’re treading water you don’t punish the survivors of the titanic for not also doing laps while they wait to be rescued.
Given you’ve made no comment as to expanding the team, I can only assume the business owner wants to make more money without investing in this product. There’s no magical advice that will unfuck the executive level if that’s the case.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#480So uh, good luck. You're going to be the one everyone hates.
I'd just quit in your shoes, to be completely honest. Your desire for a solid foundation will never be seen as anything but a roadblock to an organization that just wants more floors added to the house with reckless abandon for safety.
Any securities gained by improvements you champion will go unnoticed. You will be blamed when the inevitable downtime from molding a mountain of shit into less of a mountain of shit happens.
You are going to lose this fight. Please just quit and go work for a software engineering organization, you seem to have taken a job at a sausage factory for some reason. I'd also try to learn from that...
Good luck.