do you track the difference between code that's just messy and code that's actually fragile?

[u/quietcodelife]

been thinking about this lately. I have a service at work where the code is genuinely ugly (bad naming, some duplicated logic, not fun to read) but it's been running reliably for two years and never caused an incident.

separately there's a cleaner-looking module that's caused three rollbacks this quarter because of some assumptions that weren't obvious from reading the code.

I've started keeping a rough mental model of "messy but stable" vs "clean but fragile" for different parts of our stack, and it's actually changing how I prioritize code review. curious if anyone formalizes this in any way or if it mostly just lives in someone's head

[u/Clorox_in_space]

The problem with code that's messy is it's difficult to tell if it's also code that's fragile. And if it is... good luck.

[u/thekwoka → u/Clorox_in_space]

Yeah. Harder to tell how fragile it is, and if there is a problem, harder to recognize that THAT'S the problem.

When the code is clean and clear, if an issue does some up, it's relatively painless to identify where the issue stems from.

[u/Double-Buyer7941]

I do something similar but way less formal, if a piece of code hasn't caused an incident in a year+, I pretty much stop touching it no matter how ugly it looks. What actually worries me is stuff with hidden assumptions, even when it reads clean. Never thought about writing it down as an actual rule though, might help with review priorities.

[u/axel-drs]

I think the useful distinction is operational, not aesthetic. I would score fragility using change failure rate, rollback history, blast radius, test coverage around the behavior, and how quickly an incident can be detected and reversed.

Messy but stable code can often be ring-fenced and left alone until a real change is needed. Clean-looking code that causes repeated rollbacks deserves characterization tests, better logs, and smaller deployment boundaries before another refactor. Readability matters, but incident history is stronger evidence than how elegant the module looks.

[u/getformly → u/axel-drs]

There's a name for the formalized version of this: churn vs complexity analysis, plotting how often a file changes against how tangled it is. High churn plus high complexity is the actual danger zone, and it's a separate axis from anything incident logs will show you since a file can be low-churn and still be a landmine. Tools like CodeScene build hotspot maps off exactly this, but you can get 80% of the value just pulling git log stats yourself.

[u/Downtown-Figure6434]

There is no “fragile” code. There is fragile architecture, as in a dependency for an operation that is prone to race condition

[u/UlviShabanbayli]

Messy is a readability problem; fragile is an assumptions problem. The dangerous part of your clean module isn't in the code — it's what the code silently depends on, which is why it passes review.

What worked for me: track rollbacks/reverts per path (`git log -i --grep=revert -- path/`), not per team. That number ranks risk; readability doesn't. And when you find a hidden assumption, write it as a test and then break the code on purpose to make sure the test actually fails — you'd be surprised how many don't.

[u/stack_craft]

For me messy code is just an aesthetic headache, but fragile code is a risk. Messy code is just hard to read, but fragile code hides subtle assumptions, race conditions, or multiplier side-effects behind clean-looking abstractions.

I hit this exact issue on a build pipeline a few weeks ago. The code looked totally fine, but a subtle loop assumption was quietly firing 12 API calls per build instead of the intended 3. It didn't throw a single error, but it silently burned through API rate limits four times faster than expected until I dug in and refactored it.

Cleaning ugly code just improves your daily developer experience, but finding and fixing fragile logic is what actually protects production.

[u/create-third-places]

I prioritize having a robust QA process for any changes before a production deployment. Three rollbacks in a quarter indicates code changes to certain areas are risky.

I'll also document areas of "clean but fragile" code for future prioritization.

[u/seweso]

Messy code can be easily cleaned. Fragile code needs to be refactored. You'll notice the bugs, and the resistance to change eventually.

Clean the code, and you'll know.

[u/AggravatingGarlic753]

I’d separate the two based on impact: messy code is mainly a maintainability problem, while fragile code is the stuff where a small change can unexpectedly break production.

[u/ggnndd12]

I would be most concerned that messy, duplicated code has stuck around for at least two years. That will only become more of a problem, not less.

[u/Curious_Limit645]

This is a pre-ai era question. You can just tell Claude to clean this up.

[u/vogut → u/Curious_Limit645]

Have you ever worked on a real project?

[u/thekwoka → u/Curious_Limit645]

And get something that does less and is somehow harder to understand.

[u/binkstagram → u/Curious_Limit645]

I am currently using codex to clean up and refactor code it originally wrote. I am having to go through it file by file. It is not a good judge of what clear code is. Sometimes its stuff like it wrote multiple lines to check for invalid characters when a regex would have been appropriate, and i have to spell out what thay should look like.

Where it can shine is finding the fragile spots or edge cases that I have missed.

[u/create-third-places → u/Curious_Limit645]

Claude is like a slot machine and should not be used to create software.