Creating Software Is Farming, Not Architecture

January 12, 2026

We call it software architecture, but that metaphor has always felt wrong to me. Buildings are finished. Software never is.

The architecture illusion

When we design a system, we draw boxes and arrows. We talk about foundations, load-bearing walls, blueprints. The language of construction implies that at some point the work is done — that you can step back, admire the building, and move on.

But no codebase I've ever worked on has behaved like a building. They grow. They rot. They require constant tending.

A better metaphor

A farmer is never finished. You plant things, and some thrive while others don't. Weeds appear. Seasons change. The soil needs attention. You prune, reshape, and sometimes pull things out entirely.

This is what maintaining software actually feels like.

• Refactoring is pruning — cutting back overgrowth so the important parts get sunlight.
• Technical debt is weeds — harmless at first, then suddenly everywhere.
• Deprecation is composting — letting old things decompose to nourish new growth.

What this changes

If creating software is like the farming business, then the role of the developer isn't to build and leave — it's to tend and adapt. It means maintenance isn't a lesser activity than creation. It means the most important skill isn't designing the perfect system upfront, but noticing when something needs attention.

The best codebases I've seen weren't the most cleverly designed. They were the most lovingly maintained.

A question to sit with

If we stopped thinking of ourselves as architects and coders and started thinking of ourselves as farmers, how would that change the way we plan projects, estimate timelines, and value the people who keep things running?

Sometimes the most valuable thing you can do is pull a weed.