The counterpoint to this is "Rough Prototypes have a bad habit of being shipped out as End-Products". And technical debt 'does' kill products.

There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.

I would say technical debt is a better problem to deal with. At least the project is alive at that point and you are able to get feedback from actual users.

> an optimum somewhere in the middle

Reasonable code isn’t technical debt. The obvious tipping point is when spending X hours now likey saves people less than X hours in the future. Which unfortunately depends a great deal on the details of the actual project involved and therefore requires experience not some universal methodology.

Sure, in the other extreme they never got shipped in first place, and that marvelous piece of art ended up in a museum.

It is a balance that needs to be learnt, and a trait of seniority.

It depends, if it has a bunch of nested loops and easily abstracted code but it works sure, who cares. If someone decides to store JSON as a string in the db that will work and deliver business value, but 8 months later when you want to query information in that JSON string you have a very difficult/dangerous migration due to someone just "making it work".

This philosophy less relevant in larger companies with more engineers also.

One of the traits of seniority is to understand what that "it depends" means in reality.

Do you know of any RDBMS's that can't take a text column and treat it as BSON?

I get your point, I just question the specific example.

I don't care if it's pretty.

Make it work and make it as straightforward as possible.

If by "straightforward" you mean "readable" I agree. If I can read it easily, it's pretty enough.

There are a ton of people at all levels that don't get this.

I think it was Judd Apatow who said “You have to give yourself permission for the first draft to be shit.”

The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.

Problem is the business will often never let you improve it.

So you better not tie your self worth to the quality of the things you produce.

It's not a universal thing.

You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them.

You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.

Surely, I have given up to the pretty tribe on a couple of pull requests, as I have better things to do with my time, and it is easier to make their wishes come true than endless arguing.

> Undelivered pretty code doesn't deliver any business value.

See also: https://apenwarr.ca/log/20211024 (Wants, needs, and chasm crossing).