[trentgreene]

Some of the most impactful code I've written has been absolutely trash. Like, really, really bad. By almost all objective measures, terrible. Except for the results it helped bring about. By that one measure, it was excellent, damn near perfect code

[now__what]

Likely because if the effect of "bad" code is positive enough, you have incentive to just let it keep on being "bad" and not touching it, so you can keep reaping the benefits.

Also, if you're on a tight timeline for a critical function, you may want to push ugly/inelegant/dense/"bad" code just to get the function in prod a day sooner. This doesn't mean the code isn't "bad," it just means that the business needs outweigh the ugliness.

[arethuza]

I wrote some really trashy code in what was supposed to be a "proof of concept" where I had about 7 days to write something that would be shown to the executive committee of the very large company I was working for at the time.

Then I was told the CEO and CFO wanted a preview in 3 days....

That was 12 years ago, still in production as far as I know!

[The functionality was supposed to be replaced with something built in or integrated with the new ERP system.... but that project crashed and burned].

[joombaga]

Oh man I have some bash case statements that fit this description. Could be improved, but it's tested with every commit on every PR and by George it really holds the room together.

[jiggawatts]

I've seen snippets of the back-end code of a public cloud, and it is full of multi-page "switch" statements where they have hard-coded lookup tables for what SKUs support what features.

It's ugly, it's a maintenance headache, but it does function, and very robustly too. There are no API calls, no microservices, no performance issues, etc...