Software is Grown, Not Built

Software engineering as an industry, as a discipline, is being held back by the construction metaphor.

We talk about building software. We discuss architecture. We lay foundations. We design infrastructure. We worry about plumbing. Entire organisations, from executives to engineers, are quietly guided by this language of construction, and because language shapes thought far more than we like to admit, we have spent decades importing assumptions from physical construction into a medium where many of those assumptions are not merely unhelpful, but actively destructive.

This would be harmless if it were just semantics. But it isn’t.

Construction is a profoundly poor model for how software creates value, how software survives uncertainty, and how software should evolve over time. Worse, because construction is familiar, tangible, and socially intuitive, it creates a false ideal about how software delivery should work; how it’s “supposed” to look.

Everyone understands how a building goes up. Dig the hole, pour the slab, erect the frame, finish the structure, fit out the internals, then eventually open the doors. It is linear, dependency-heavy, and for most of its lifecycle delivers no practical value whatsoever.

That model makes perfect sense when you are dealing with steel and concrete. It makes absolutely no sense whatsoever when your medium is rocks that we tricked into thinking.

Yet we persist in this farce - structuring projects, governance, funding, and delivery expectations as though software is made of something, and cares about the laws of gravity.

It isn’t - and it doesn’t.

Software Can Be Useful Immediately

If you are constructing a skyscraper, there is no meaningful version of an “MVP”. An incomplete building does not partially solve office space problems. A hospital with no roof or windows is not incrementally valuable. Until the system is largely complete, signed off, and safe, its value curve is effectively flat - often negative - because all it represents is sunk cost, risk, and capital expenditure.

Software is one of the few major industries where this is fundamentally untrue.

A software product can generate value absurdly early. A single useful workflow can save time. A narrow internal tool can reduce labour. A landing page can validate demand. A prototype can disprove a million-dollar mistake. A tracer bullet through a system can illuminate what matters before full-scale investment begins.

This is not a minor distinction. It should radically alter how we think and talk about software.

The value curve of construction tends to resemble deferred payoff: long periods of cost accumulation followed by a dramatic jump once complete. Software, at its best, should look more like iterative compounding: launch, learn, refine, expand, correct, scale. Its value curve can zig-zag upward from day one.

The critical point here is not simply speed, but cumulative value. The total area under that value curve over time is dramatically greater than the grand-reveal approach, even if the final product takes a less linear path.

Software Is Like Trees

Software - done well - behaves far more like a living system than a static structure, and one of the most useful mental models is not the skyscraper, but the redwood.

A redwood does not begin by first producing an enormous root system, a nine metre wide and hundred metre tall trunk before daring to deploy branches and leaves. If it did, it would die almost immediately - massive cost, zero energy production, no adaptive capacity.

Instead, it starts small. Even within an established forest, every new tree begins this way.

A sapling produces just enough structure to survive for now. It extends just enough roots to stabilise itself and draw water. It grows leaves early, because leaves generate energy. That energy creates capacity for more roots, more trunk, more branches, more leaves. The system expands in proportion to proven need and available resources. Its architecture is real, but adaptive. Its design exists, but unfolds responsively.

And that is what good software delivery looks like.

The smallest useful version should create enough value, learning, or strategic confidence to justify the next layer of investment. You do not grow a giant trunk before you have enough branches and leaves to both support and genuinely require that structure.

Architecture exists in a form, it lives in the tree’s DNA. But that “architecture” is not a blueprint, it’s not a plan, it’s a procedure that allows structure to emerge proportionate to validated growth - not speculative fantasy.

And that is what good software architecture looks like.

Software Exists in a Moving Environment

Construction assumes relative environmental stability. Soil tests happen first because the land is expected to remain broadly what it is. Weather patterns are modelled. Regulations are known. Constraints are front-loaded. The environment is treated largely as a fixed problem to solve against.

Software does not exist in a physical space, and so it doesn’t have this same luxury.

By the time you ship, competitors have moved. User expectations have shifted. New technologies may have changed what “good” looks like. Internal strategy may have pivoted. Regulatory or platform constraints may have evolved. In many cases, launching your product changes the environment itself by influencing user behaviour.

This means software requirements are not static truths waiting to be implemented, they are moving approximations of current understanding, and that fundamentally changes what is meant by “complete”.

If you spend twelve months “building” software in isolation and only then expose the result to users, you are effectively betting that your understanding of the world remained accurate while the world itself changed around you. You will lose that bet every time.

Software Projects are not Construction Projects

Most experienced engineers already understand iteration at a conceptual level, the problem is that our language quietly shapes the expectations of everyone around us, and often even tricks ourselves.

Executives hear “foundations” and may assume long invisible phases are prudent. Stakeholders hear “architecture” and may assume deep, structural thought is required for every problem. Teams hear “build” and subconsciously default toward rigid planning and completion bias, rather than challenging, sharpening and validating ideas before attempting to scale them.

Construction language does not just describe work - it legitimises particular kinds of work that are not valid in the world of software.

It encourages:

• Foundations over feedback
• Planning over process
• Building over learning
• Execution over adaptation
• Sequential work over collaborative work

This is how organisations end up six or twelve months deep into massive initiatives that are technically sophisticated, strategically expensive, and entirely functionally misaligned with what users actually needed.

It’s not because people were stupid - or even wrong when they started - it’s just because they were thinking like builders instead of growers. And we are doing nobody any favours, least of all ourselves, by continuing to use these metaphors blindly.

Better Language Builds Better Systems

Change the metaphor, change the world! Imagine replacing “How do we build this?” with “How do we grow this?” Capturing sunlight becomes a metaphor for generating value.

Instead of “what does the MVP look like?” we have “what does the sapling that can sustain itself look like?”:

• How do we throw out leaves early?
• Which way do we need to grow to break through the canopy?
• Which branches need thickening under real load?
• Which branches should be pruned?
• How thick does the trunk need to be to hold everything up in a storm?

Growth thinking naturally prioritises adaptation, sustainability, and compounding learning - where roots slowly dig their way down over time as the usable structure above requires.

Construction thinking prioritises static planning and execution - where it’s necessary to dig a big hole before you can even start on the usable part of the structure.

Software doesn’t win by being completed - it wins by generating enough value to sustain its growth over a long period of time. Just like a redwood tree.

Stop Pouring Concrete Into a Living Medium

Software’s greatest advantage has never been that it can be perfectly planned - its advantage is that it can change very quickly.

When we force software into construction-shaped systems of thought, we surrender one of the medium’s greatest strategic advantages.

So, stop pretending software is a skyscraper. You are not an architect, you are a silviculturist. You are not a builder, you are an arborist. That is not foundational work it’s soil preparation. It’s not infrastructure, it’s ecology. You’re not plumbing, you are irrigating.

Ok, that last one is a bit of a stretch. I think I’ve made my point.

The best software products are not “constructed”, they are grown through iterative exposure to reality, strengthened by feedback, and shaped by changing conditions.

I think the industry and craft will improve in leaps and bounds the moment we stop obsessing over how to build software, and start learning how to grow it instead.