alt Hacker NewsBad code works fine until it doesn't. In my experience, with humans, doing the right thing is worth it over doing the bad thing if your time horizon is a few months. Once you're in years, absolutely do the right thing, you're actually throwing time away if you don't. And I don't mean "big refactor", I mean at-change-time, when you think "this change feels like an icky hack."
For LLMs, I don't really know. I only have a couple years experience at that.
Replies
If you are a company founder, what scenario would you rather find yourself in?
a) a pristine, good codebase that follows the best coding practices, but it is built on top of bad specs, wrong data/domain model
b) a bad codebase but it correctly models and nails the domain model for your business case
Real life example, a fintech with:
a) a great codebase but stuck with a single-entry ledger
b) a bad codebase that perfectly implements a double-entry ledger
And it’s perfectly okay to fix and improve the code later.
Many super talented developers I know will say “Make it work, then make it good”. I think it’s okay to do this on a bigger scale than just the commit cycle.
> Bad code works fine until it doesn't.
Who is to judge the "good" or "bad" anyway?
The fix time horizon changes too, don't discard that.
But tech debt with vibe coding is fixed by just throwing more magic at it. The cost of tech debt has never been lower.
If you make a working and functional bad code, and put it on maintenance mode, it can keep churning for decades with no major issues.
Everything depends on context. Most code written by humans is indeed, garbage.