[reese_john]

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]

"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]

> 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]

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.