"Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." a quote sometimes credited to Albert Einstein.
Software engineering, when judged as a discipline of engineering aspires to a rigor that lives up to skyscraper construction and aircraft production.
Soft ware or hard, engineering suggest an expectation of meticulous process and precise outcome. If you do exactly these you get exactly that, no exception.
The fact that the term engineering has been relegated to an umbrella term in software to encompass all areas of development is an indication of 'engineers' not living up to that ideal and/or not care anymore.
Here is where fishes are judged by how they climb the tree of engineering. It has been a false narrative all along.
An empty garden is a problem of imagination, anything is possible. Once the garden is grown movements are constrained. Constraints are built in, creativity is called for.
Building version 1.0 of anything is easy (as long as it's something people want). It's version 2.0 that's hard and progressively so.
A single plant is easy to control, even if it's a farm of disconnected potted plants. Take away any pot and no other pot would care.
Plants connected by the same soil is a different story. At an unknown point in time they became an emergent ecosystem. They probably talk to each other in way we dunno about.
Attempts at true control here illusory. What's really available for influence are individual units, in the hope that there is no chain reaction taking down the whole ecosystem.
The advise for modularization of code, containerizations, etc. are really desires to minimize connections of each elements to avoid them emerging into an out of control ecosystem. The intention is noble, but with growth comes emergence.
Given enough time with emergence, the ecosystem develop unique characteristics with strengths and weaknesses. It has grown into something you need to respect.
Engineers do not expect bugs. Having bugs are failures in design and execution.
Gardeners expect bugs. They rather not have it, but having bugs are not failures. It's part of the game.
Debugging is not a necessary evil. It becomes a forensic pursuit, an opportunity towards antifragility.
Weak roots/designs make weak plants/software.
They are hardly visible but foundational. Overtime they grow complicated, getting a clear picture becomes difficult.
Their effectiveness gets reflected in the trunk/computation-output.
Undoing-designs/regrowing-roots becomes close to impossible.
Trimming bad trunks allow nutrients to go only to good trunks.
Trimming bad code takes away attention given to them.
Refactoring makes room for good designs to emerge.
The easiest subject for bikeshedding, but still worth highlighting.
The fact that your spade/editor is how you get gardening/coding done is only half the story.
A good tool opens up new possibilities that may have never occur.
To beginners, the tool is the gateway to learning the subject (often at the danger of confusing the tool and the craft itself).
A good tool gets out of the way of your craft, stays in the background without consuming your attention.
In warriorhood, being one with your sword is a matter of life and death.
A Siberian gardener harbours no expectation for growing tropical plants. In fact he is focused on growing the best thing Siberian climate can offer.
Users, stakeholders, designers, programmers, markets and all manner of human factors make up the entirety of climate to the growth of a software.
Under certain combinations of climate, some software simply does not take place, even if it's something that can be coded in a weekend.
Conversely under the right climate, some software becomes inevitable.
Software gardening is not new, and I don't see reasons for it to catch on. Compared to engineering and craftmanship, gardening simply lacks sex appeal.
As a club of its own, engineers secretly know they are playing in an infinite game, one in which consist of multiple finite games.
Nobody in this game gets exactly what they want, and that's okay. Participants/stakeholders are detached from rigid outcome, so long as the software keeps on living (being used).
Just like no two plants are the same, no two software are created the same way, even if they set out to achieve the exact same thing.
Therefore similarly, beauty is more than a combinations of features and aesthetics. It includes the journey it went through to become what it is.
From original post
