Live data from Hacker News

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

news.ycombinator.com

581–590 of 704 posts

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

#581

Earlier quoted context omitted.

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…

> 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. Emails are writing, if you're imagining the IT lead walking in with a paper contract I see why you would say that.

That's essentially what the GP was implying, "Have everything in writing, complete with date and signatures."

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

#582
post #572

Earlier quoted context omitted.

If such a team of 3 people comprised of script kiddies and 5y PHP coders are going to create a $20m/year product, you can be sure that they will take precedence over anyone who was 'properly' educated in cs when it comes to hiring. > I'm sure it happens Yeah it does happen. While using the Internet, quite frequently, you are looking at such products developed by such teams, making millions of dollars a year. Even as…

The shitty software probably isn't the product. It could be some sales/inventory management tool or whatever, that before they got some 'script kiddies' in was just some forms in Microsoft Access (is that what it's called.. the forms on top of database tool we had to learn in ICT at school) orwwhatever. I think many people here are reacting to $20M forgetting not everything's a SaaS/in the business of selling softwar…

> The shitty software probably isn't the product

The shitty software is what sells the product, from the description. Even if the shitty software is a sales/inventory management tool or 'whatever', from the description it is obvious that it is vital to whatever business they are doing.

It doesn't matter whether it was built with Microsoft Access and Excel files. If its contributing a major part of that $20m /year, its not shitty, its golden.

Anyone who understands the trials of modern business, including any tech lead who had to deal with even merely stakeholders and low-level business decisions would prefer to have a $20 m/year sh*t before a well-crafted, 'properly built' architecture. The difficult thing is getting to that $20 m/year. The difficulty of rearchitecting or maintaining things pale in comparison to that.

> I think many people here are reacting to $20M forgetting not everything's a SaaS/in the business of selling software (but mostly still has some (in-house) software somewhere).

Everyone is aware of that. Many are also aware that getting to $20m/year in WHATEVER form is more difficult than architecting a 'great' stack & infra.

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

#583
Sounds like everything works just fine. Nothing to worry about, as long as there are no dependencies it will just continue to work. Add some more code and see if the millions continue to flow in. Logs and tests sounds fun.

index-new_2022-test-whattodochange_v1.php

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

#584
There’s a lot of sane suggestions here, but one thing I’m not grokking: what is your role here? You say you don’t manage this team in your post. In what sense have you inherited this responsibility, and what levers do you have to set direction for the project or people involved.

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

#585
post #134

Earlier quoted context omitted.

I think you've not witnessed Ship of Theseus, but "build Ship2 next to Ship1 and start using Ship2 while Ship1 is still being used and keep saying you're going to migrate to Ship2 eventually but meanwhile Ship1 and Ship2 diverge and now you have 2 ships". I recently witnessed this mess and it is an enormous mess. Don't build Ship2 in the first place. Instead, replace Ship1's mast and sails, and rudder etc until you'v…

Right but how do you replace the masts? Don’t you have to build mast2 and then tear down mast1 if you want to have continuous propulsion?

Yes, can you see how that's quite different from building a second ship?

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

#586

Earlier quoted context omitted.

> That is how it should be done in any case anyway. Not exactly. IT management should be always telling people stuff like "did you notice that the integration with XYZ that never worked well stopped failing?" or "did you notice that we delivered those few last features at record time?" and explaining why.

That is assuming that things are failing. $20m/year with 3 people does not look like anything is failing to me.

That is assuming things are improving. If you aren't improving anything, then yeah, you don't have anything to say.

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

#587
I think doing a full rewrite is the least thing you should consider. You should think first the least risky things to this mess. Remember your team is small and the revenue is huge(20M/year lol). I will list some things to consider (importance order) and the others can consider more points, of course:

- git: More productive and more control over the code base and the each member team responsibilities. Don't change the structure of the code. If it's a monorepo, leave it as it is. Just create simple branches like, prod and dev. Consider putting nginx configuration into the repositories as well (since it's part of the application).

- Documentation Via Comments: In this part you should improve a little of culture in this team, new code should be documented at least using comments.

- Test environment: now you have a dev branch you can push all the code to this new test environment and test things without worries. If it's possible start to write configuration environment case it's needed.

- CI/CD: now everything is traceable by git, you can write a routine to deploy every branch on it's place. Some tools self hosted you can consider: Jenkins or Drone.io are great and requires almost no maintenance(no need to hire a devops to work on this)

- Database: you have test environment and ci/cd, now you can TEST(what a great news) your database migrations. In php I can remember of phinx to starting to write migrations for this application.

- Auto Tests: I think unit testing could be considered when adding new code. Old code just leave as it is.

If you apply at least 3 things of this list I think at this point you will see that's a rewrite could be not that necessary.

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

#588
post #559

Earlier quoted context omitted.

Yeah, there's a process. It's something that I've done a bunch of times for a bunch of clients. There's so much low-hanging fruit there that's so easy to fix _right now_. No version control? Good news! `git init` is free! PHPCS/PHP-CS-fixer can normalise a lot, and is generally pretty safe (especially when you have git now). Yeah, it's overwhelming, but OP said that the software is already making millions - you don't…

Personally, I would never run a linter of any kind on a full codebase that doesn't have tests. After having been bitten by all kinds of bugs over the years, I wouldn't suggest auto-linting any file that you aren't actively working on. It's rare that linting will actually make the code work better. Granted, it could catch some security bugs. But they can - and will - introduce new bugs. You just have to ask if it's wo…

This. It's so tempting when a linter warns "This code is misleading; it would be clearer to do it this other way" to think "Easy fix: change it the way the linter suggests." But, make the change, and you may discover (hopefully before delivery) that the code functionality depends on the confusing behavior.

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

#589

First 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…

> Writing tests for something that is already not functional, will be a waste of time.

This is not TDD; it's writing tests to confirm the features that work now. Then, when you make changes, you can get an early warning if something starts going south.

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

#590
post #53

Plenty of good suggestions in here about e.g. tests, source control etc. You will need them all. But I would start by choosing how and whether to fix up the crown jewels, the database. You say that instead of adding columns, team has been adding new tables instead. With such behaviours, it's possible your database is such a steaming pile of crap that you'll be unable to move at any pace at all until you fix the datab…

Good point. Using stored procedures / views etc will help crystalise the API for the DB and allow work to happen behind that wall without breaking anything else in the meantime too. Once the work is done, bits of the wall can be replaced with better bits of wall i.e. improved sp's and views pointing to an improved schema.

Yep. views in RDBMS are much underrated, IMO just because they are old tech. It should be possible to use views to:

1) normalise the database (fold these ugly add-on tables as columns in the parent table, with suitable null constraints, then drop the add-on table).

2) Use views to add the add-on tables (now views) back in again.

3) Continue running the old application code against the views, which present the old, ugly schema.

4) Simultaneously write the new code against the normalised core tables.

Post reply on HN