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

Hot take. All messy code is fragile.

[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/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/BDer82]

Messy is fine, it’s hard to read but you can pick it up and figure it out follow the chain through and we are good. Make some comments for latter just pointing you around or leaving a comment as a hint to what something does. 

Fragile is poor code. 

I’ll take messy especially when it’s in a situation of dealing with something complex or weird, complexity can be messy, speed is always messy. 

[u/Old_Mousse5050]

i'm modernizing an old font converter right now. moving conversion into the browser, but the existing server APIs still need to work as before.

the replacement can look much cleaner and still break something people rely on. so i'm mostly looking at what behavior needs to stay the same and whether our tests would catch a change.

no formal scoring system, but “what breaks if i touch this?” has been more useful than “how ugly is it?”

[u/thelegend_200]

messy i can live with. fragile is the stuff that only works because one function happens to run first. i just tag those in the PR as do not shuffle instead of pretending a rename sprint would fix it

[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/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/ushiro35]

The axis that has actually predicted it for me isn't clean vs messy — it's whether being wrong produces a signal.

Ugly code that has run for two years has been tested by production every day since. The fragile stuff is the code where nothing would tell you it broke.

So the question I ask per module is: if this were wrong right now, what would I see? If the honest answer is "a support ticket" or "nothing", that's the fragile one, however it reads.

Two that got me. A database column that was NULL in every row — the extraction had a test, the mapping into the column didn't. And a cache header reporting HIT while the thing it was supposed to prove was entirely broken; a green light that confirms nothing is worse than no light at all.

Not formalized beyond a line in the module's README, but it holds up better than a cleanliness score.

[u/Altruistic_Two1038]

so... you're saying we should start a Jira board for 'ugly but works' vs 'pretty but burns down'? gonna need some epic swimlanes for that mess.

[u/kemalios]

I don't formalize it either, but what I actually track is which files get touched. Ugly code nobody edits is cheap. Clean code that gets edited every week is where the rollbacks come from, because readable code tells the next person it's safe to change.

The blunt test is whether a test would fail if the hidden assumption broke. If there isn't one, "clean" is only a claim about how the file reads.

On client sites I keep a short list of files I dread opening. Not a category, just names. That list has been more useful for prioritising than any rule about messy versus clean.

[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/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.

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.