Hacker News Board Hacker News, browsed like a classic message board
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

Post reply on HN
Print view View original

241–250 of 704 posts

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

#241

Post by tauwauwau »

simonw wrote: post #95

Here'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…

How do you make sure that code being committed is ready to be run, files could be saved before they're ready. I'm assuming this won't happen on production server, but you can't be sure if it's just code workspace for someone.

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

#242

Post by pkolaczk »

lumost wrote: post #66
latchkey wrote: post #32

Earlier quoted context omitted.

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

The problem with people new to the company starting a rewrite from scratch is that they often are poorly informed on why things were the way they were before. If you start big, you can have bad outcomes where the new system might be objectively worse than the old one... but you are stuck trying to get the new thing out for the next 5 years because too many people sunk too much political capital into it. As an example…

You're making a silent assumption that the original team is well informed about why the things are like they are and that they know what they are doing. I think it is not always the case.

I've been to a project once where the mess in the original system was the result of the original team not knowing what they were doing and just doing permutation based programming - applying random changes until it kinda worked. The situation was very similar to that described by the OP. They even chose J2EE just because the CTO heard other companies were using it, despite not having a single engineer knowing J2EE. Overall after a year of development the original system barely even worked (it required manual intervention a few times per day to keep running!), and even an imperfect rewrite done by a student was already better after 2 weeks of coding.

So I believe the level you're starting the rewrite from is quite an important factor.

Then of course there is a whole world of a difference between "They don't know what they are doing" vs "I don't like their tech stack and want to master ". There former can be recognized objectively by:

- very high amount of broken functionality

- abysmal pace at which new features are added

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

#243

Post by sph »

bsaul wrote: post #192
speedgoose wrote: post #118

Earlier quoted context omitted.

Yes, life is too short and there are so many much better jobs to waste time on such a project.

i can imagine how some super senior engineer may like this kind of very challenging experience.

A super senior consultant might: they are paid by the hour/day and they are free to fire the client and leave if the working situation becomes too hairy.

As an employee, the best advice is GTFO.

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

#245

Post by atoav »

The most important thing is that you communicate right now.

From the HQ perspective they make a lot of money with very few developers and all seems to be going well, with no problems at all. Judging by the spreadsheets this looks great!

Your task is now to explain to them the risks involved with proceeding forward. You can also present them a plan to mitigate that risk without interrupting ongoing operations too much and slap some money figure on it — ideally you present them three options where one of those is doing nothing. Be aware that the decision on this is not yours, it is theirs. Your task is to tell them everything relevant for that decision. You can also tell them, that your professional opinion is that this is something that ahould have been done years ago and the fact that this didn't explode in their faces yet was pure luck. But again it is their decision.

How you lay it out depends on you, but there have been many tips already. Version control might be the first thing. Maybe you can present it as: one day a week goes towards maintenance or something.

As an aside this helps to cover your own behind if nothing is done and everything goes south in a year. Then you can point to that extensive risk analysis you presented them with and tell them you told them so.

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

#246

Post by wizofaus »

latchkey wrote: post #32
codingdave wrote: post #13

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…

> We did a full rewrite and it was quite successful and the company went on to triple the revenue.

Which sure beats some other company coming along and "rewriting" the same or similar functionality in a competing product and killing your own revenue. But it does come down to how big the codebase is and how long it would take for an MVP to be a realistic replacement. If there are parts that are complex but unlikely to need changing soon you can usually find ways to hide them behind some extra layer. Is there any reason you couldn't just introduce proper processes (source control, PRs, CI/CD etc.) around the existing code though?

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

#247

Post by password4321 »

simonw wrote: post #95

Here'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…

DB schema and prod/devops config too!

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

#249

Post by password4321 »

tauwauwau wrote: post #241
simonw wrote: post #95

Here'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…

How do you make sure that code being committed is ready to be run, files could be saved before they're ready. I'm assuming this won't happen on production server, but you can't be sure if it's just code workspace for someone.

This doesn't.

It's not perfect, it's a step in the right direction.

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

#250

Post by rawoke083600 »

Rewrites aside, (it may or may not improve or work) but the thing I have noticed/learn about HUGE codebases which are 'bad' is to implement "feature-options" and have an "unbreakable rule" about coding to a client/actor/instance.

Nice thing is you can start with the current codebase, and add in these, it will make the rewrite a lot easier since your capabilities/feature-configs are already extracted.

Example:

If your product/code serves multiple customers, you should never have:

    if (customer-id==123 || customer-id==999) {
       //do things this way
    }else {
      //do things the other way
    } 


 instead always aim for feature-options (config?)

  if (config-feature-a == true){
       //do things this way

    }else {

      //do things the other way

    }
If this seems not related to your codebase or product, you just need to dig deeper, it's usually there in some form or another.

PS. If you think the above is 'obvious', you have probably not seen an old enough (or bad enough ?) codebase, few coders start out with the bad case, the bad-case (coding to a instance/customer) are those 'quick-fixes' that accumulate over the years.

Post reply on HN