Hacker News new | past | comments | ask | show | jobs | submit login

That's the thing. Not making the problem worse is fine and all, but most projects simply aren't removing enough. It's amazing that today's software functions as well as it does, and programmers today are lucky they can hitch a free ride on decent hardware.



In a thread elsewhere (mastodon, I think?) the idea of using a Copilot-like LLM as an assistant in removing code was suggested as * a way to use an LLM with less discomfort about model provenance (since you wouldn't be using anything it generated ) * a way to get over some user cynicism (waves) about whether an LLM usefully "models" the code.

Of course, at the time noone thought copilot could actually do any of that, but it was a few weeks ago and things are moving quickly.


Yeah. Refactors and rewrites (i.e. removing lots of code) are risky, but so is having critical CVEs and data loss events every year because of your insanely over-complicated architecture that has never been rethought in the past decade+.

It's a cultural issue where we think major faults "just happen" and are not directly tied to prior product decisions, and therefore there isn't much accountability.

But if you propose a major refactor, there is no question about (rightly) where the blame lies.


Modern software is so buggy, but it's considered the norm. I was talking to a non-technical person recently about that, and although they were at first puzzled by my view that most software is problematic, they realized that they experience the same bugs I complain about all the time. It's become so normal that people hardly notice it, but that doesn't make it better because bad software wastes human life time whether they realize it or not.

> But if you propose a major refactor, there is no question about (rightly) where the blame lies.

LOL Yep.

Worse is when the blame lies on the semi-technical cofounder of your company who, granted, achieved quite a lot on their own, wrote a barely maintainable mess. Do you really want to be the one to indirectly point out that his code needs to be replaced? Haha I think a lot of developers would rather wait for the Dilbert Principle to kick in so that the cofounder gets out of the way enough for significant changes to finally be made.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: