Anti Clean Code: The F.L.U.I.D. Trap ⚠️

Learn about the five key ways a code can go wrong and know what to be careful about. (6 minutes)

Petar Ivanov

Jun 29, 2025

Every team wants to write clean, maintainable, scalable, and testable code.

We often read about SOLID principles, Clean Code, and other best practices.

These practices help us write code that is easy to change and extend.

Yet in real life, many projects and codebases fall into the opposite trap.

Let’s call this pattern the “F.L.U.I.D” code.

This code is Fragile, Lax, Untested, Insecure, and Disorganized.

Understanding these anti-patterns helps us identify problems early on and take corrective action to get the project back on track.

What Is F.L.U.I.D. Code?

FLUID is an acronym for five key ways a code can go wrong.

Fragile
Lax
Untested
Insecure
Disorganized

When code exhibits one of these traits, it often drags in the others.

For example, a fragile module that breaks easily will also be hard to test and secure.

By recognizing the aspects of FLUID code teams can learn to spot bad traits of the code and change the trajectory.

Fragile Code

Fragile code is code that is easily broken by unrelated changes or updates.

A small tweak in one module can trigger many bugs in other modules and features.

Fragile code breaks in unexpected ways.

When teams are dealing with fragile code, they start to lose confidence in the codebase.

They spend more time firefighting bugs and tracing problems, instead of building features and delivering value.

Teams become reluctant to touch or change a piece of code because of the fear of not breaking something else.

And this is contagious if not spotted on time and acted upon it.

⛔ Fragile Code might come from:

tight coupling between modules
large functions with many responsibilities
no clear boundaries or interfaces
lack of tests

✅ How to start fighting Fragile Code:

extract responsibilities into small, focused, and manageable functions
define clear interfaces and public methods
start writing tests (even simple ones) to prevent regressions

Lax Coding Standards

Inconsistent style across the codebase makes the code harder to read, follow, maintain, and even review.

When everyone has their own conventions and way of writing code, the codebase becomes a frankenstein.

It becomes a nightmare to onboard new team members and merge pieces of code and functionality.

⛔ Lax Coding Standards might come from:

no agreed upon style guide
lack of automated tooling (formatters, linters, etc)
weak or absent code review process

✅ How to start fighting Lax Coding Standards:

adopt a common style guide or create one for your team and company
enforce formatting with tools like ESLint, Prettier, etc.
include style check in your CI pipeline

Untested Code

Without tests, you don’t know if a change breaks an existing behavior or not.

You can’t be confident if product work as expected after your changes.

You might wait for customers to complain but this strategy might cost the company a lot - loosing existing customers and money.

There are also teams that apply “test in production” behavior but this strategy can’t give you strong confidence and could also lead to many outages.

⛔ Untested Code might come from:

tight deadlines and pressure to ship
no testing culture and rules or skills gap
legacy code without a testing framework

✅ How to start fighting Untested Code:

start small and simple - add a few tests to cover core flows and scenarios
integrate a testing framework (like Jest, Vitest, etc)
require tests for new features or bug fixes before merging

Insecure Code

Security flaws can let attackers steal data and shut down the whole system.

A single vulnerability inside the codebase might cost millions of dollars to the company - from legal fines to reputation damage and losing customers.

Imagine a login endpoint which fails to sanitize user input, allowing SQL injection.

This can let the attacker dumb the entire database in seconds.

Investing in security early on saves time and money in the long term.

⛔ Insecure Code might come from:

skipping input validation
implementing your own auth instead of using proven libraries
no static analysis or security audits

✅ How to start fighting Insecure Code:

validate and sanitize all input
use battle tested libraries for encryption and authentication
automate security scans (ex: Snyk)

Disorganized Codebase

A messy project is hard to navigate and reason about.

Developers waste time searching for files and features or tracing down duplicate code.

Then can even wonder where to put the new functionality.

Imagine a developer trying to build a new feature but can’t find whether an existing utility function is present or not.

So he decides to build his own, wasting time and effort.

This type of mindset can lead to enormous technical debt which will be very hard to pay down with the time going.

New hires might also get lost inside the codebase.

Clear and organized codebase improves the overall team efficiency and onboarding speed of new colleagues.

⛔ Disorganized Code might come from:

no agreed upon folder or module structure
large “god classes” with thousands of lines
copy-pasted code, instead of shared utility functions or modules

✅ How to start fighting Disorganized Code:

define a clear project layout (ex: Bounded Contexts, feature-based modules, page-based folders, etc)
enforce module boundaries and single responsibilities
regularly review and pay down tech debt, remove dead or duplicate code

The Vicious Cycle of F.L.U.I.D. Code

Each FLUID trait in the code fuels the others.

Fragile code is hard to test, so it remains untested.

Untested code hides security holes, so it remains insecure.

Insecure code requires quick patches leading to lax coding standards.

And lax coding standards might lead to chaotic and disorganized codebase.

Over time, a once clean codebase becomes a FLUID trap.

📌 TL;DR

FLUID - anti clean code pattern; Fluid, Lax, Untested, Insecure, Disorganized.
Fragile Code - small changes break other features, causing many bugs; teams start to fear making changes in the code.
Lax Coding Standards - no shared style guide; poor code reviews and many merge conflicts.
Untested Code - no automated tests; might lead to production regressions.
Insecure Code - skips input validation and sanitization; security breaches.
Disorganized Code - no clear project structure; duplicate code; confusion in team members.