[deleted]
Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
361–370 of 704 posts
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#362I'm sorry to hear that. Must be a terrible situation. I've seen similar projects, at least in some dimensions. Here's what worked for me & observations:
- Large fraction of features are unused. Have internal analytics that will answer you which features/code paths are used and which are safe to delete/ignore. It's much easier to migrate xx% of features than have 1:1 parity.
- Lack of tests is a huge pain. Makes incremental migration near impossible. Find a workaround for it before jumping to migration (forcing huge code coverage increase for already submitted code never worked for me in the past)
- See if some parts can be proxied. Put proxies in place and migrate features behind it (in one past project, the logic was split between stored procedures in Oracle DB, backend code and js code -- which made it possible to proxy stored procedures and break the migration in milestones)
- Hackatons are great tool for exploring options, uncovering blockers and dedicating a large chunk of focused time. Make it clear that the result is experimental, not that it must be merged to main. A nice way for introducing frameworks, vcs etc. without high friction.
The rest depends on the management support, the teams aptitude, intake of feature requests & bugs, the difficulty of maintenance etc. You are the best to judge how to approach there.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#363First 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…
+1. came here to say this! it's in prod, making money; bring up the discussion of full rewrite with the management at your own peril. learn to tame the beast by pruning one dead/redundant function at a time, that's the best you can do, both for the project and for yourself!
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#364Earlier quoted context omitted.
This is the right way to think about it. My only disagreement is that I'd do the local DB before the local service. A bunch of local versions of the service pointing at the production DB sounds like a time bomb. And it's definitely worth emphasizing that having no framework, MVC, or templating library is not a real problem. Those things are nice if you're familiar with them, but if the team is familiar with 2003 vint…
> if the team is familiar with 2003 vintage PHP, you should meet them there. That's still a thing you can write a website in. You can write a website in it, but you cannot test it for shit.
If this is true, OP can consider writing tests of the website using a frontend test suite like Cypress, especially with access to local instances connected to local databases.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#365First 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…
My first instinct was "get some testing in place" too. That served me well in recent projects where I was in a similar situation. I was wondering if anyone has any advice on how to make sure your tests are... comprehensive? I was fortunate enough to have full flow tests in place from the beginning and a great team which knew the intricacies of the subject matter. We made lists of usecases and then tried to find ortho…
One more thing I’d add; for the love of all that is holy make sure the tests run lightning quick.
What you want to do is first reduce the cost and risk of making changes, to a close to zero as possible.
Then, come up with a broad system design that defines higher levels of abstraction. Your goal is not to redesign the system from scratch but to specify the existing hierarchies which are currently implicit in the code. Are there different modules that naturally emerge? Ok, what are they?
Once you have a sense of what the destination will look like, make tiny changes to get just one module done. Move in little bits at a time, to build up evidence that things can work.
The way to change a culture is to set such a strong positive example that people naturally went to follow. Telling other people their work sucks is not that example, but first pitching in to speed up development cycles can make everyone happy.
And lastly you have at least some responsibility to inform management of the risk they aren’t aware of. Things will go much better for you if you tell your manager that the codebase was built in a way that makes future changes expensive and risky, and this is fine for where the business was but at some point it makes sense to invest in shifting the development velocity/risk curve of the business.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#366A 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…
> Next, make it possible to spin service up locally, pointing at production DB. I think this is bad advice, just skip it. I would make a fresh copy of the production DB, remove PII if/where necessary and then work from a local DB. Make sure your DB server version is the same as on prod, same env etc. You never know what type of routines you trigger when testing out things - and you do not want to hit the prod DB with…
I am inclined to agree. The other advice was excellent, but pointing local instances to production databases is a footgun.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#367Here'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.
You don't, but the current system doesn't do that either. That comes later down the line. Baby steps and all that!
A path to doing this might look like: - Cron job scraping and committing - add a post commit check that runs a linter/some checks/tests - assign out fixes to these issues - ask for those fixes to be done using git - pick an area to focus on, and enforce coverage in that area. You can still blindly deploy here, but at least you know when it's broken
As noble a goal of testing before deployment is, sometimes it's an enormous amount of effort to change development practices, workflows, team mindset and company mindset. You can only handle some of these at a time so choose a combination of the low hanging fruit (maybe there's a separate component) and the highest impact (every time this breaks the site goes down)
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#368Kill it with Fire, by Marianne Bellotti is an excellent resource on this question. She addresses the team dynamics, corporate politics and technical side of modernizing legacy systems.
https://www.penguinrandomhouse.com/books/667571/kill-it-with...
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#369As somebody that inherited a similar mess, spent 5 years of their life on it, made a lot of progress, but still didn’t fully “fix it” in the end, let me caution you a bit before you embark on this quest.
Consider the opportunity cost of cleaning up this mess. Consider the years of your life spent. The impact to your career. The stress.
In my opinion, unless the compensation is legendary OR this is something you feel very strongly about taking on, you might consider taking a different and more fulfilling role.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#370First 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…
+1. also start by adding git first and have a test env set up.
A new person who complains about existing code and proposes "Rewrite everything" on week one, will not met with __respect__