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

261–270 of 704 posts

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

#261

Post by jmillikin »

peteradio wrote: post #35
rowanG077 wrote: post #27

Earlier quoted context omitted.

Huh. You are literally saying do a full rewrite. But it's also the worst idea? Edit: A full rewrite always meant replacing every part of a system. Whether you do it gradually doesn't really matter.

Full rewrite generally means stop the presses we are gonna migrate this whole thing from here to there and no new features until it's done (hint it never gets done).

A "full rewrite" means that after the completion of the rewrite, the old code has been fully replaced by new code.

What you're describing is a "stop-the-world" rewrite.

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

#262

Post by forty »

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…

Yeah, I agree, full rewrite from scratch are almost never the good approach. It will start a tunnel when you cannot add anything useful to production for months, and you will have no idea when you can finally ship the whole thing and when you do, it will be very risky.

Do things progressively. Read the code, figure out the dependencies, find the leaves and starts with refactoring that. Do add tests before changing anything to make sure you known if you change some existing behaiors.

Figuring out such code base as a whole might be overwhelming, but remember that it probably looks much more complicated than it is actually.

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

#263

Post by gocartStatue »

Top of mind: - Teach the team vcs 101, put the code under vcs; do trunk-based - ask about critical places in code and add logging - implement dead simple feature/experiment toggles - set up an example: develop all new changes as simple functions using TDD - put yourself in „harm’s way”. Do a live coding stream where you show your team how you do it. - If they like it, offer to do pair programming sessions. - add composer and start moving dependencies there, one by one - repeat 100x

That’ll be 200$ lol

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

#264

Post by plonk »

throwaway002ha wrote: post #190
rocqua wrote: post #172

Earlier quoted context omitted.

This is more reason for the gradual approach. Bringing source control, testing, and separation of dev and prod environments, makes things safer and will speed up work pretty soon by making the people much more comfortable to actually try things.

For what benefit in the end for the individual?

I've done that progressively over two years as a junior and I'm basically unofficial tech lead now. Managers listen to me and I can plan and influence several projects. I have other goals so I won't become official team lead by choice, but that's probably valuable to OP if he can pull that off.

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

#265

Post by 41b696ef1113 »

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.

The system is an enormous black box and this at least tells you what N things were being manipulated at time in point X. Easy to setup and gives just a bit of peace and mind if the thing keels over one day.

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

#266

Post by morbia »

cool-RR wrote: post #116

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

A lot of people see this as a technical challenge, but it is a political one. The road the business took to get to this point is crucial, and understanding whether the business want to fix it is key.

In my experience once businesses get into this sort of mess they will never work their way out of it. To use an analogy, there is a point where people who make terrible lifestyle choices (smoking, obesity etc) where the damage is too far gone.

A company I used to work for had a horrendous codebase that was making them a ton of revenue. It wasn't as bad as the OP's codebase, but it was pretty terrible. It was wedded to a framework that was abandoned 8 years ago. Everything was strongly coupled to everything else, meaning it was brittle. Every release they'd have to have an army of QA testers go through it and they'd find 100's of new bugs. Every bug that got fixed introduced another.

The lesson I learned? Find these things out during an interview. Ask about their CI, ask about QA and automated testing and really push them on details. If they give vague answers or something doesn't smell right, walk away.

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

#268

Post by jensneuse »

I love this! Others have pointed out already how to untangle the mess, so I'd like to point out one important fact. You can generate 20M in revenue with absolute shit Code. Yet a lot of devs over engineer software that never generates a single dollar in revenue. Sure, there's not just black and white. It's definitely a nightmare. But I think a lot of code is "too good". Always make sure that the code paths you drive to perfection are actually generating value for the user.

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

#269

Post by oftenwrong »

I have been in similar situations.

Code can be fixed, but people sometimes can't be. You need to break down the "resistance to change" somehow. Trying to convince people can burn a lot of time and effort on its own. If you can't easily convince them, and you can't overrule them to dictate the direction, don't even bother.

You need people and you need budget. The business doesn't understand bad code, but you should find a way to make them feel fear. They have been drinking poison for years without feeling ill. Make them understand how easily the house of cards could come crashing down.

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

#270

Post by 41b696ef1113 »

lordnacho wrote: post #200
gamegoblin wrote: post #37

Earlier quoted context omitted.

He’s saying to Ship of Theseus the codebase. Don’t build a new ship and then burn down the old ship. Replace the old ship piece by piece in place.

That only works if the new pieces correspond to old pieces. If there's no good structure to build on, the units to be replaced will constrain the architecture of the new ship. At some point you end up trying to change a pumpkin boat into an aircraft carrier, and there's no obvious way you can do that one piece at a time.

Maybe there are some underlying architectural problems that need to be addressed, but it would be impossible make those changes from the current situation. It sounds like it is impossible to even know what code is live vs sitting on the server. How do you even know you have a firm grasp on the current architecture when it is unclear what code is even running the product?

A lot of low hanging fruit to be addressed that will likely lead to meaningful improvements. Once the code is in better shape and some unfortunate legacy pattern is identified, than it can be considered time to re-tool the architecture.

Post reply on HN