Before the Structure Rots

1. Counting the lines

One day I opened an automation workflow file and counted the lines. 908.

It had started at a few dozen. Every new feature added a little more. For a while, it wasn't a problem. It worked. It was useful. Then one day I tried to add something new and realized: I couldn't immediately tell where anything was.

That was the sign that rot had begun.

2. The gravity of the monolith

A monolith is a structure where everything has been consolidated into one place — one file, one system, everything packed together.

Monoliths have strong gravitational pull. When adding something new, it's faster to write into an existing file than to create a new one. To avoid breaking what already works, you fit the new thing inside the existing structure. That accumulation is what causes files to bloat.

The initial choice is usually correct. When things are small, a single consolidated structure is easier to read. The problem is not updating that judgment. The moment arrives when the structure needs rethinking — but "it's still working" keeps it in place. That's where decay begins.

3. Three signs of structural rot

There are a few signals that tell you a structure has started to decay.

The first is "I can't find what I'm looking for." When opening a file and scanning for a specific piece of logic takes time, the structure has grown too complex.

The second is "I'm afraid to change it." When editing one part and being uncertain about effects on other parts creates excessive caution, the coupling has grown too tight.

The third is "adding something new feels like a burden." When extending the system — which should feel generative — becomes heavy with concern for the existing structure, it's time for a redesign.

4. The principle: one file, one responsibility

The first question in refactoring is: what actually needs to be together?

The 908-line file contained 14 different actions — project management, file operations, email sending, voice memo recording. Each was an independent process. Yet they lived in the same file, for no reason other than being executed in the same context.

"Executed together" and "needs to be together" are different things. Even if the timing is the same, things with different responsibilities can be separated. Each action was moved to its own file.

Before: one configuration file (908 lines) with 14 Python scripts mixed in
After: one configuration file (184 lines) + 17 independent action files

The configuration file became a place for one thing only: what to run. How to run it moved to individual files. With clear roles, reading and editing became fast.

5. The misunderstood cost of refactoring

The belief that "refactoring takes time" is half right and half wrong.

Yes, in the moment it takes time. Decomposing what works, reconstructing, testing, confirming. That work is real.

But the comparison is being made against the wrong thing. The right comparison is: time spent refactoring vs. the accumulated cost of continuing to add features on top of a rotting structure. As decay progresses, each change takes longer. Bugs increase. Time to understand the code increases. That accumulation far exceeds the cost of refactoring.

Fixing the structure early is cheaper overall. This is a classic insight from software development, and it applies equally to personal infrastructure.

6. "Before adding more" as the decision point

There's a useful question for timing a refactor: "If I try to add the next feature to this structure, will I hesitate?"

If the answer is yes, that's the signal. Fix the structure before adding the next thing. It's much easier to add after fixing than to fix after adding.

In practice, this refactoring was decided the moment a new action was about to be added. The feeling of "I don't want to put this into the current structure" arrived immediately. That feeling was trusted. Feature addition was paused. Structure repair came first.

Afterward, adding a new action took two steps: create a file, add one line to the configuration. On the rotting structure, it would have meant checking impacts on existing code throughout. The difference was substantial.

7. Rot is the sum of well-intentioned choices

Structural rot doesn't come from someone making a bad design decision. It comes from many individually reasonable decisions accumulating into something that no longer works.

The first ten lines were right. Fifty lines was fine. Two hundred started feeling heavy. Five hundred was clearly burdened. At nine hundred, it had reached its limit. But no single decision along the way was wrong. The problem was that the judgment "this needs rethinking" was never updated.

This pattern isn't limited to code. Organizations rot the same way. Habits. Relationships. Unintentional accumulation of reasonable choices eventually reaches a limit. Major surgery when it's fully rotten. Small maintenance when it's just beginning to turn.

8. The design posture for long-running systems

When designing a system meant to run for a thousand years, maintaining structure matters more than adding features. No matter how good the functionality, code that can't be read eventually becomes code no one will touch.

"Fix it before it rots" is a technical stance, but it's also a stance toward time. Choosing long-term sustainability over short-term speed.

Watch for the signs of decay. Stop when hesitation appears. Deliberately create moments where structure repair takes priority over feature addition. That is what grows infrastructure that lasts.