3 ms·

Bad 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 m

Bad 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.

tokioyoyo 6mo ago
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.
- lucketone 6mo ago
  I define maintenance mode as: given over to different team, so not my problem anymore.
- bsder 6mo ago
  > Most code written by humans is indeed, garbage. I think that this is the problem, actually. It's similar to writing. Most people suck at writing so badly that the LLM/AI writing is almost always better when writing is "output". Code is similar. Most programmers suck at programming so badly that LLM/AI production IS better than 90+% (possibly 99%+). Remember, a huge number of programmers couldn't pass FizzBuzz. So, if you demand "output", Claude is probably better than most of your (especially enterprise) programming team. The problem is that the Claude usage flood is simply identifying the fact that things that work do so because there is a competent human somewhere in the review pipeline who has been rejecting the vast majority of "output" from your programming team. And he is now overwhelmed.
  - thesz 6mo ago
    > Most programmers suck at programming so badly that LLM/AI production IS better than 90+% (possibly 99%+). How do you know?
    - bsder 6mo ago
      Because of just how many programmersI've interviewed who can't pass FizzBuzz? I also taught upper level CS and my first assignment was always "You have 10 days. Here is a 10 line program on this sheet of paper. Type it in, check it into source control, and make the automated tests go green. Warning: start today." 1/3 of the class couldn't finish that task and would drop.
Aperocky 6mo ago
The fix time horizon changes too, don't discard that.
devy 6mo ago
> Bad code works fine until it doesn't. Who is to judge the "good" or "bad" anyway?
- thesz 6mo ago
  It is important to question "how to judge," not "who is to judge." My answer of "how to judge?" question is the question "how easy is it to implement new unforeseen functionality with the code under scrutiny?"
strulovich 6mo ago
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.
- a96 6mo ago
  https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast Make it work, make it work right, make it work fast. In that order.
peder 6mo ago
But tech debt with vibe coding is fixed by just throwing more magic at it. The cost of tech debt has never been lower.
reese_john 6mo ago
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
- SpicyLemonZest 6mo ago
  "Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box, and the issue with bad code is that it can make it extraordinarily hard to solve simple problems. I have personally seen tech-debt induced scenarios where "I want a new API to edit this field in an object" and "Let's do a dependency upgrade" respectively became multi-month projects.
  - reese_john 6mo ago
    > Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box Fair, by “perfectly implements” I meant to say that it correctly implemented the core invariant of a double entry ledger (debits = credits), not that it was 100% bug free
- progmetaldev 6mo ago
  Since most won't actually deal with fintech (I don't know the stats on HN, but I'm talking devs as one industry), your first "a" example might actually be better than your first "b" example, depending on the complexity of the software. In lots (probably most) of industries, having a good codebase would mean architecture decisions were solid, but the domain/service layer is bad. Maybe my experiences don't match most of the HN crowd, but usually I get stuck with very detailed domain/service rules, but the architecture is a problem where too much memory or CPU is being used, just to abstract away the actual rules of the application (the purpose). Usually when I've been brought in to rebuild an application, the client is fine with the results, but they are upset over performance and/or cost to run the application. For anything of actual complexity, it's usually the supporting code that is the biggest failure, because complex apps usually have decent requirements. Now, if the requirements were bad, and the architecture was bad, AND the domain/service layer is bad, I don't know if there's anything to fix that.
butlike 6mo ago
But why not rewrite the app, change the name, and get shareholder value from a new product announcement? It shouldn't take a long time, the spec for the new product is the old product being rewritten. See Google Hangouts > Google Chat

tokioyoyo 6mo ago

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.

lucketone 6mo ago
I define maintenance mode as: given over to different team, so not my problem anymore.
bsder 6mo ago
> Most code written by humans is indeed, garbage. I think that this is the problem, actually. It's similar to writing. Most people suck at writing so badly that the LLM/AI writing is almost always better when writing is "output". Code is similar. Most programmers suck at programming so badly that LLM/AI production IS better than 90+% (possibly 99%+). Remember, a huge number of programmers couldn't pass FizzBuzz. So, if you demand "output", Claude is probably better than most of your (especially enterprise) programming team. The problem is that the Claude usage flood is simply identifying the fact that things that work do so because there is a competent human somewhere in the review pipeline who has been rejecting the vast majority of "output" from your programming team. And he is now overwhelmed.
- thesz 6mo ago
  > Most programmers suck at programming so badly that LLM/AI production IS better than 90+% (possibly 99%+). How do you know?
  - bsder 6mo ago
    Because of just how many programmersI've interviewed who can't pass FizzBuzz? I also taught upper level CS and my first assignment was always "You have 10 days. Here is a 10 line program on this sheet of paper. Type it in, check it into source control, and make the automated tests go green. Warning: start today." 1/3 of the class couldn't finish that task and would drop.

Aperocky 6mo ago

The fix time horizon changes too, don't discard that.

devy 6mo ago

> Bad code works fine until it doesn't. Who is to judge the "good" or "bad" anyway?

thesz 6mo ago
It is important to question "how to judge," not "who is to judge." My answer of "how to judge?" question is the question "how easy is it to implement new unforeseen functionality with the code under scrutiny?"

strulovich 6mo ago

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.

a96 6mo ago
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast Make it work, make it work right, make it work fast. In that order.

peder 6mo ago

But tech debt with vibe coding is fixed by just throwing more magic at it. The cost of tech debt has never been lower.

reese_john 6mo ago

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

SpicyLemonZest 6mo ago
"Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box, and the issue with bad code is that it can make it extraordinarily hard to solve simple problems. I have personally seen tech-debt induced scenarios where "I want a new API to edit this field in an object" and "Let's do a dependency upgrade" respectively became multi-month projects.
- reese_john 6mo ago
  > Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box Fair, by “perfectly implements” I meant to say that it correctly implemented the core invariant of a double entry ledger (debits = credits), not that it was 100% bug free
progmetaldev 6mo ago
Since most won't actually deal with fintech (I don't know the stats on HN, but I'm talking devs as one industry), your first "a" example might actually be better than your first "b" example, depending on the complexity of the software. In lots (probably most) of industries, having a good codebase would mean architecture decisions were solid, but the domain/service layer is bad. Maybe my experiences don't match most of the HN crowd, but usually I get stuck with very detailed domain/service rules, but the architecture is a problem where too much memory or CPU is being used, just to abstract away the actual rules of the application (the purpose). Usually when I've been brought in to rebuild an application, the client is fine with the results, but they are upset over performance and/or cost to run the application. For anything of actual complexity, it's usually the supporting code that is the biggest failure, because complex apps usually have decent requirements. Now, if the requirements were bad, and the architecture was bad, AND the domain/service layer is bad, I don't know if there's anything to fix that.

butlike 6mo ago

But why not rewrite the app, change the name, and get shareholder value from a new product announcement? It shouldn't take a long time, the spec for the new product is the old product being rewritten. See Google Hangouts > Google Chat