Vaibhav Kumar Kandhway | Full-Stack Developer

The engineering philosophy nobody teaches you — and what three real projects revealed about disorder, decisions, and the cost of change.

Introduction

There is a specific kind of frustration that every developer eventually encounters.

Your code works. The tests pass. The pull request is merged. And then three weeks later, something completely unrelated breaks. You trace it back. You find the cause. And you realise it was not a bug that broke your system.

It was a decision you made three weeks ago that nobody questioned.

This is software entropy. And once you understand it, you cannot unsee it.

This post is not a theoretical overview of entropy as a concept. It is an account of what building three production projects — PredictiveCare, CuraSense, and Allma Studio — revealed about how codebases actually degrade, why the conventional response makes things worse, and what a genuinely entropy-resistant architecture looks like in practice.

What Software Entropy Actually Is

The term entropy comes from thermodynamics — the second law of which states that any closed system naturally moves toward disorder over time. Energy dissipates. Structure breaks down. Without deliberate intervention, things become more chaotic, not less.

Software systems follow the same principle.

Every change you make to a codebase — every feature addition, every bug fix, every refactor, every dependency update — introduces a small amount of disorder into the system. A new edge case handled with a special condition. A workaround added because the "proper" fix would take too long. A dependency introduced because it solved the immediate problem without anyone evaluating its long-term implications.

Individually, each of these changes seems harmless. Collectively, they accumulate.

This accumulation is software entropy. The codebase becomes harder to understand. Changes that should be simple become risky. New features require touching more and more existing code. The system starts resisting change in ways that are difficult to diagnose because no single commit is responsible — the problem is the sum of every small decision that was never properly resolved.

The critical insight is this: software entropy is not caused by bad developers. It is caused by decisions that seemed reasonable at the time but were never examined for their long-term implications. It is the result of ignorance — not incompetence.

And this is why ignorance is more dangerous than bugs.

A bug crashes your system. It announces itself. You fix it. Done.

An unchallenged assumption lives silently in your codebase, shaping every decision built on top of it, until the accumulated weight of those decisions makes the system unmaintainable.

How I Encountered Entropy in PredictiveCare

PredictiveCare is an enterprise-grade IoT solution for predictive maintenance of industrial machinery. At its core is an ensemble machine learning pipeline combining XGBoost, LightGBM, and CatBoost models to predict equipment failure from sensor data.

The early versions of the system worked. The models trained. The predictions were reasonably accurate. The dashboard rendered sensor data in real time.

But the codebase had a problem I could not see yet.

Each iteration of the ML pipeline was built as a patch on top of the previous one. When the XGBoost model needed a preprocessing step that LightGBM did not, I added a conditional. When the feature engineering for the meta-learner diverged from the individual models, I added another special case. When the prediction output format changed for the dashboard, I updated three separate places.

The system kept working. But it was becoming increasingly brittle.

When I tried to introduce a fourth model — a neural network for time-series anomaly detection — the codebase resisted in a way I could not immediately explain. Adding the new model required understanding and modifying six separate parts of the pipeline that were all subtly coupled to each other in ways that no single file made obvious.

This was entropy made visible. Not in a crash. Not in an error. In friction.

The fix was not adding more patches. It was restructuring the pipeline so that each model was a completely self-contained module with a defined interface. The ensemble coordinator did not care how any individual model worked internally. It only cared about what went in and what came out.

One structural decision. The entropy stopped accumulating.

The Counterintuitive Philosophy: Fewer Patches, Not More

The instinctive response to a failing or degrading system is to patch it. Fix the immediate problem. Restore functionality. Move on.

This is wrong. Not always. But often enough to matter.

Every patch you apply to a system is a vote for disorder. It adds complexity. It adds surface area for unintended interactions. It adds another special case that the next developer must understand before they can safely modify the surrounding code.

The professional philosophy — and the one that building these projects eventually forced me to adopt — is the opposite of the instinct:

Increase the number of problems one patch solves. Not the number of patches.

This means spending more time understanding the root cause before writing a single line of fix. It means asking not just "what is broken" but "why is this the kind of thing that can break here." It means designing fixes that eliminate the conditions that made the failure possible — not just suppressing the symptom.

This is slower in the short term. It is dramatically faster over the lifetime of the system.

How CuraSense Made Disorder Structurally Impossible

CuraSense is an AI-powered healthcare platform that handles three distinct capabilities: prescription analysis and medical insight extraction, medical imaging diagnosis using Gemini Vision for X-rays, CT scans, and MRIs, and drug comparison including medication interactions and alternatives.

Three complex AI capabilities. Three entirely different data types. Three entirely different models and processing pipelines.

The architectural decision that defined the entire project was made before a single line of implementation code was written:

Every capability is a completely independent module. Prescription analysis does not know that imaging exists. Drug comparison does not depend on either. The only shared layer is the API surface that the frontend consumes.

This decision was not made because I was disciplined about clean code. It was made because I had already learned from PredictiveCare what happens when capabilities are allowed to know about each other.

The result was an architecture where entropy had no room to accumulate between modules. Adding a new capability — say, a lab result interpreter — requires zero changes to any existing module. It is a new module that plugs into the existing API surface. Nothing that exists needs to be modified.

This is the practical meaning of the DRY principle taken to its architectural conclusion. Do Not Repeat Yourself is not just about avoiding duplicated code. It is about ensuring that every piece of knowledge — every capability, every rule, every transformation — exists in exactly one place in the system. When it changes, it changes in one place. The cost of change stays flat as the system grows.

The DRY Principle: The Cost of Change Must Stay Small

DRY — Do Not Repeat Yourself — is one of the most cited principles in software engineering. It is also one of the most superficially understood.

Most developers learn DRY as "do not copy paste code." Extract a utility function. Create a shared component. Avoid writing the same logic twice.

This is correct but incomplete.

DRY at its deepest level is about the cost of change. Every time a piece of knowledge exists in more than one place in your system, the cost of changing that knowledge multiplies by the number of places it exists.

Consider a concrete example. You have date formatting logic written in three components — a product listing, an order summary, and an invoice. The same transformation. Three implementations.

The date format requirement changes. You update the product listing. You forget the invoice. Your system now displays three different date formats to the same user on the same screen.

This is not a bug. It is a decision — the decision to repeat yourself — finally revealing its cost.

DRY says extract that logic into a single utility. Call it from all three places. When the requirement changes, it changes once. The cost stays flat.

But this principle extends far beyond functions and components. In CuraSense, DRY means that the rules for what constitutes a valid prescription analysis request exist in exactly one place — the prescription module. The imaging module does not duplicate those rules. The drug comparison module does not reference them. Each module owns its own knowledge completely.

When the prescription analysis rules change, one module changes. The system does not have to be searched for every place that knowledge might have leaked.

The ETC Principle: Easy To Change

If DRY is the structural enforcement of entropy resistance, ETC — Easy To Change — is the test.

Before you write any code, ask one question: if the requirement for this changes tomorrow, how hard will it be to modify?

If the answer is very hard, your architecture is already wrong. Not wrong because it does not work today. Wrong because it will not survive contact with reality.

Requirements always change. This is not a risk to be managed. It is a certainty to be designed for.

ETC is why component-based architectures exist. A component that does one thing, does it well, and exposes a clean interface can be modified without touching anything else. A component that is tightly coupled to its neighbors — that knows too much about the system around it — becomes a liability the moment its requirements evolve.

In Allma Studio — a local AI chat platform built on RAG and Ollama — the ETC principle shaped the most fundamental architectural decision in the entire project: the decision that all AI processing happens locally, with no cloud dependency.

This was not just a privacy decision. It was an ETC decision.

A cloud-dependent AI system that needed to become privacy-first would require changes at every layer — the API calls, the data handling, the authentication, the storage. The change would be expensive because the dependency on cloud was baked into every part of the system.

Starting from "your data never leaves your machine" as the root architectural constraint means that privacy is not a feature to be added. It is a property of the system by design. Changing the AI model requires changing one configuration. Adding a new model requires adding one entry to the supported models list. The system is easy to change because the decisions that would make it hard to change were eliminated before the first line of code was written.

Allma Studio: One Decision, One Category of Complexity Eliminated

Allma Studio is a privacy-first AI chat application with RAG capabilities, running entirely on a local machine via Ollama. No cloud. No subscriptions. No data leaving the device.

The architectural philosophy of the entire project can be expressed in one sentence:

Rather than patching privacy concerns onto a cloud-dependent system, eliminate the dependency on cloud entirely.

This is the entropy philosophy applied at the highest level. The most powerful patches are the ones that eliminate an entire category of problems — not the ones that suppress individual symptoms.

Cloud-dependent AI systems have a category of problems: data privacy, API costs, rate limits, latency, offline availability, dependency on third-party service uptime. Every one of these problems requires its own patch if you start cloud-first and try to become privacy-first later.

Starting local-first eliminates the entire category. Zero data privacy patches needed. Zero API cost management. Zero rate limit handling. Zero dependency on external uptime.

One architectural decision. One entire category of complexity: gone.

This is what entropy-resistant design looks like at scale. Not discipline. Not clever code. Structural impossibility of the disorder you are trying to prevent.

The Deeper Lesson: Context Over Code

The most important insight that building these three projects produced is not technical.

It is this: the code you write is less important than the decisions you make before you write it.

A perfectly written function that solves the wrong problem is worthless. A simple, inelegant solution that correctly eliminates a category of complexity is invaluable.

Software entropy teaches you that the systems you build will eventually be maintained by someone else — or by a future version of yourself who has forgotten the context in which the code was written. The question is not whether your code is clever. The question is whether it is honest — whether it makes its assumptions visible, its dependencies explicit, and its purpose clear to anyone who reads it six months from now.

The DRY principle, the ETC principle, and the entropy philosophy are all expressions of the same underlying idea: build systems that are honest about what they are, conservative about what they depend on, and designed to change gracefully when reality demands it.

Because reality always demands it.

Summary: The Practical Checklist

Before you write your next architectural decision, ask:

Am I patching a symptom or eliminating a root cause?
If this requirement changes tomorrow, how many places in the codebase will I need to touch?
Does this component know things about the system around it that it does not need to know?
Am I introducing a dependency that will be harder to remove than to add?
Am I making disorder structurally impossible — or just disciplining myself not to introduce it?

If the answers to these questions make you uncomfortable, the architecture needs rethinking before the implementation begins.

Every patch you add is a vote for disorder.

Make it count.

About the Author

Vaibhav Kumar Kandhway is a final-year Computer Science student at VIT and a full-stack developer building production-ready applications in React, Next.js, and Node.js. My projects — CuraSense, PredictiveCare, and Allma Studio — are live, used by real users, and documented at vaibhavkandhway.dev.