Each Other
general · 2 signals · 1 source
Evidence
How do you tackle a backlog of deferred maintenance you didn't create? — I don't mean migration in the sense of switching databases or rewriting in another language. I mean that a codebase rots if nobody maintains it. Deprecations, warnings, upstream changes — each is cheap to handle the moment it appears, often a 10-minute fix (let's say 'in average'). But plenty of teams never catch them. No real CI/CD, no culture of reading changelogs or acting on warnings. So it piles up silently, and then at some point — usually when an infra or security team shows up with tickets — the whole accumulated pile lands on one person at once. Often a new hire or a junior who's never seen the code, with no record of why any of it is the way it is beyond git blame, a stale changelog, and a few dead chat threads. What I think gets underestimated is that clearing it all at once costs far more than the sum of the small fixes would have. The problems tangle into each other, and the context that would let you separate them is already gone. So I'm trying to learn from people who've been dropped into this. What did you actually reach for, and what worked — tests, diffing output before/after, shadowing prod traffic, or just running it and hoping? Did anyone try LLM agents, and where did they genuinely help versus confidently make things worse? (I know of an Angular case where the agent kept patching a function it assumed was the problem, and after a couple of failed runs invented its own workaround — when the correct approach was in the docs the whole time). Just time spending. If you can ballpark it: how much worse was all-at-once versus incremental — 3x, 10x? And one thing I keep wondering: when you were reconstructing a system like this, what were you missing more — a description of what the code does, or of what someone meant it to do? Those feel like two different problems.
Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it? — I have to find a strategy to fix this development team without managing them directly. Here is an overview:<p>- this code generates more than 20 million dollars a year of revenue<p>- it runs on PHP<p>- it has been developed for 12 years directly on production with no source control ( hello index-new_2021-test-john_v2.php )<p>- it doesn't use composer or any dependency management. It's all require_once.<p>- it doesn't use any framework<p>- the routing is managed exclusively as rewrites in NGInX ( the NGInX config is around 10,000 lines )<p>- no code has ever been deleted. Things are just added . I gather the reason for that is because it was developed on production directly and deleting things is too risky.<p>- the database structure is the same mess, no migrations, etc... When adding a column, because of the volume of data, they add a new table with a join.<p>- JS and CSS is the same. Multiple versions of jQuery fighting each other depending on which page you are or even on the same page.<p>- no MVC pattern of course, or whatever pattern. No templating library. It's PHP 2003 style.<p>- In many places I see controllers like files making curl requests to its own rest API (via domain name, not localhost) doing oauth authorizations, etc... Just to get the menu items or list of products...<p>- no caching ( but there is memcached but only used for sessions ...)<p>- team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge.<p>- productivity is abysmal which is understandable. The mess is just too huge to be able to build anything.<p>This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers. And post COVID, budget is really tight.<p>I know a full rewrite is necessary, but how to balance it?