Software gardens

I keep hearing the phrase “software factory” as teams adopt agents and more automated development workflows. I understand the appeal. A factory sounds efficient. It suggests repeatability, throughput, quality control, and a system that can take a clear input and produce a reliable output.

That metaphor works when you already know what you are making. Most interesting software starts earlier than that. It starts as a question, a conversation, a weird prototype, a customer insight, a half-formed workflow, or a note you captured weeks ago and finally understand. At that stage, the work is less about manufacturing and more about cultivating the conditions for good ideas to survive.

This is why I prefer software gardens.

A garden still has structure. You decide what to plant. You make space. You water, prune, and pay attention to what is taking root. Some things grow quickly. Some need another season. Some should be composted back into the system because the idea was useful, even if the implementation was not.

Knowledge management is the soil for this kind of work. Notes, research, customer conversations, prototypes, decision logs, and old project artifacts create the material that new ideas grow from. The value is rarely in one perfect document. The value is in being able to return to something, connect it to something else, and see a pattern you missed the first time.

Conversation is the other part. Ideas grow when they move between people. A quick Slack thread, a design crit, a hallway conversation, a founder call, or a comment in a doc can change the shape of the work. Conversation adds nutrients. It reveals what is confusing, what people care about, and where the real problem might be hiding.

This matters even more with agents. Agentic software loops are powerful, but the loop should include more than code generation and review. The best loop connects product discovery with software delivery. Insights from conversations and knowledge systems should feed the backlog, shape the prompt, inform the architecture, and help decide what deserves to be built in the first place.

Otherwise, you can end up with a very efficient system for producing the wrong thing.

Software gardens make room for iteration before scale. They allow small prototypes to test the soil. They let teams keep ideas alive long enough to understand them. They also create a healthier relationship with unfinished work. Even an abandoned prototype can become reference material for the next project, a pattern for another team, or context for an agent working on a related problem months later.

The goal is to build a living system around ideas. Capture what you learn. Keep the useful parts discoverable. Let conversations change the work. Prune what no longer matters. Give promising ideas enough room to grow before asking them to behave like a product.

Factories are good at producing what has already been defined. Gardens are better for the part before that, when the idea is still becoming itself.