I Built Software Wrong for 7 Years. You Shouldn’t Do The Same.
Most engineers think like architects. That’s the mistake.
For nearly a decade, I approached every project like an architect designing a skyscraper.
Grand blueprints. Comprehensive feature lists. Meticulous upfront planning. Everything mapped out before a single line of code was written.
It felt professional. It felt thorough. It felt right.
It was also completely wrong.
After more than 7 years in this field, I've come to realise something that fundamentally changed how I build software:
We're not architects. We're gardeners.
The Architect's Trap
The architecture metaphor has dominated software development for decades. We even borrowed the terminology: software architects, system architecture, architectural patterns.
The influence runs so deep that it shapes how we think about building products.
Here's how the architectural approach typically works: you gather all requirements upfront, design the entire system, create detailed specifications, then hand it over for construction.
Once the building is complete, the architect's job is done. The structure is fixed, permanent, unchanging.
This made sense when software development was closer to hardware, when programmes were written in machine code for specific mainframe architectures in the 1950s and 1960s.
Once in production, changes were painful and rare. If the company bought new hardware, you rewrote everything from scratch. That actually resembles building construction.
But modern software? It's nothing like that.
Software is soft. Buildings are hard.
As Andy Hunt and Dave Thomas (2019) observe in The Pragmatic Programmer, rather than construction, software is more organic than concrete. It changes constantly, influenced by user requirements, business needs, market pressures, and technological evolution.
My last project taught me this lesson the expensive way. I approached it like an architect: gathered every possible requirement, defined the architecture upfront, planned for every eventuality.
The result? A big, unwieldy monster plagued by performance issues and technical debt.
We'd built a skyscraper when we needed a garden.
The Gardening Mindset
So what does it mean to think like a gardener instead of an architect?
A garden is never finished. It's constantly growing, changing, evolving.
You don't plant a garden once and walk away. You tend it continuously, adapting to seasons, weather, and what the plants themselves tell you they need.
The most important aspect of the gardening metaphor is constant change.
Different from a house where an engineer walks away once construction is finished, a garden needs continuous care.
Here's what changed for me when I adopted the gardening mindset:
1. Focus on One Plant at a Time
In gardening, you don't try to grow everything simultaneously. You focus on nurturing one plant, making sure it's healthy before expanding to the next.
In software, this means building one piece of functionality properly. Not a massive feature set. Not enterprise-grade everything. One thing that works, that users actually need, that you can deploy and observe.
When you deploy this single functionality, it begins to grow and attract attention. Users engage with it. They tell you what they need next. Just like deciding which plants to cultivate based on which ones thrive in your soil and climate.
This is fundamentally different from the architectural approach, where you try to anticipate every need upfront.
The garden approach lets users guide your growth through real usage, not theoretical requirements.
2. Accept That Things Will Change
Buildings resist change. Gardens expect it.
Software is influenced by external factors you cannot control: user requirements shift, business priorities change, frameworks update, security vulnerabilities emerge, competitors launch new features.
Treating software like a fixed structure means fighting against its fundamental nature.
Gardens change with seasons. Some plants thrive and spread. Others struggle and need to be replaced. You prune to encourage healthy growth. You remove what's no longer working.
In software terms: you refactor constantly. You remove features that aren't used. You simplify what's become complex. You rebuild components that have rotted. This isn't failure. It's maintenance. It's how healthy systems evolve.
Research shows that leaving a garden unattended leads to rot, weeds, and eventual unusability. The same applies to software.
When you don't maintain it, security issues emerge, APIs stop working, and technical debt accumulates until you need to tear everything out and start over.
3. Use the Right Tools for Your Garden
Every gardener has tools they love to work with. These don't have to be the fanciest tools, but they need to work for the type of garden you're cultivating.
You can do everything manually, but certain tools enable efficiency without over-engineering. A gardener doesn't buy industrial farming equipment for a small vegetable patch. They choose tools proportional to the garden's scale.
Software development is the same. You don't need enterprise architecture patterns for a startup MVP. You don't need microservices when a well-structured monolith would do. You don't need every framework and library just because they're popular.
Choose tools that help you tend your garden effectively. Nothing more, nothing less.
4. Understand That Growth Takes Time
Architects expect buildings to be completed on schedule. Gardeners understand that plants grow at their own pace, influenced by factors you can control (water, sunlight, soil) and factors you can't (weather, pests, seasons).
Software development works the same way. You can create the right conditions, you can use good practices, but you cannot force growth to happen faster than the system naturally allows.
When stakeholders ask, "How long will this take?" the honest answer is closer to "How long will this tree take to grow if you do everything right?" rather than "How long to build this wall?"
The first acknowledges environmental factors like legacy code quality, team experience, and unexpected challenges. The second assumes fixed, predictable construction.
This doesn't mean lack of accountability. It means realistic expectations based on organic growth rather than industrial manufacturing.
What This Means for How You Build
If you're still thinking like an architect, here's how to start thinking like a gardener:
- Stop trying to design everything upfront. You cannot anticipate all requirements. You cannot predict how users will actually behave. Build one thing, deploy it, watch what grows.
- Embrace continuous refactoring. This isn't technical debt or poor planning. It's pruning. It's weeding. It's the essential maintenance that keeps your garden healthy.
- Choose simple over comprehensive. Start with the smallest viable thing that solves a real problem. You can always expand later based on what thrives.
- Let users guide your growth. They'll tell you what they need by how they use what you've built. Listen to the garden, not the blueprint.
- Expect change and plan for it. Don't build rigid structures. Build flexible systems that can adapt as requirements evolve.
- Focus on quality over quantity. One well-tended plant is better than a dozen neglected ones. One polished feature beats ten half-finished ones.
From My Garden
The product I am building now operates on gardening principles. We started with one piece of functionality. We made it work properly. We watched how users responded.
What they told us shaped what we grew next. Sometimes their feedback surprised us. Features we thought were essential turned out to be unnecessary. Capabilities we almost skipped became central to the product.
The codebase stays manageable because we only grow what we need. Performance remains solid because we do not carry the weight of unused features.
The team stays focused because our priorities emerge from reality, not speculation.
The Builder’s Choice
You can construct software or cultivate it. Both approaches produce products. But they produce different kinds of products.
Constructed software impresses in demos. It has features for every conceivable use case. It looks complete.
Cultivated software delights in use. It does fewer things, but it does them exceptionally well. It grows with its users rather than guessing at their future needs.
After 7 years of building software, I have stopped trying to be an architect. The blueprints were beautiful. The reality was not.
Now I am a gardener. The work is slower. The results are better. And my products actually survive contact with the real world.
Start with one seed. Nurture it properly. Let your users tell you what to grow next.
That is the lesson it took me 7 years to learn. I hope it takes you less.