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 membersandmerge 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.
That's all for today. I hope this was helpful. ✌️
Credits to Kristijan Kralj who inspired me about FLUID code.