#011 — Tree. Tree. Tree.
A ticket. A task. A use case. A feature request. A bug report.
A tree. A tree. A tree. A tree. A tree.
Each one detailed, each one fascinating. Each one with its own unique qualities, its own potential defects, its own strengths and weaknesses.
As software developers, it’s easy to think that our job is to select the trees, plant the trees, water the trees, prune the trees, dig up the trees that have gotten old or diseased, etc. This leads us to forget that every software product is not a curated collection of trees, but instead is a living and constantly changing forest.
One way of thinking is that maybe tending to the forest is someone else’s job. Leave it to the business people. Or the product owner. Or to designers. Or to an architect. Or to a consultant. Whatever. But programmers are overpaid tree-keepers, and not to be trusted with seeing how the parts fit into the whole.
Another way is to let evolution do the work. Let’s plant one tree, then another, then another. Let’s see what happens. Let’s grow fast, and deal with the consequences later. Let’s put a palm tree, a pine tree, and pear tree within a few meters of one another and then observe which one the squirrels prefer.
A third way is to study every detail of every forest that ever existed, and then build a meta-framework for forestry which is capable of procedurally generating every conceivable forest, then configure it to produce the optimal forest for each customer’s needs using machine learning.
But maybe somewhere along the way, we got lost out in the weeds?
Maybe we need to go back and study systems thinking. To learn to speak the language of forests, and not just the language of trees.