There is a big difference between managing complicated systems and managing complex systems. Complicated systems (airplanes, bridges, coffee machines) are lifeless things built from scratch, piece by piece, until they're ready for use. Complex systems (gardens, households, chickens) are living things that grow, day by day, until they're mature, and then (some time later) they die.
People are careless in their use of language, and they often mix up the terminology. They talk about building living things, which is impossible. We don't build cities, we grow them. What we build are the individual houses, roads, and trash cans. What we grow are families, businesses, trees, and ugly pigeons. The sum of all that is a city, and it grows. It is not just a construction.
Likewise, we don't build companies. We grow them.
And we don't build relationships. We grow them.
We also talk about building software. And (in many cases) that's incorrect too. What we build are lines of code, design documents, and compiled assemblies. What we grow are user interaction, data repositories, social networks, and (for the systems that I grow myself) extensive bug reports and issues. The sum of all that we call software systems.
We don't build software systems, we grow them.
Unfortunately, I cannot claim this brilliant piece of reasoning as my own. It was already documented 34 years ago by Frederick P. Brooks, in his influential book The Mythical Man-Month:
The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach.
Let us turn to nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imagination, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built. So it must be with our software systems.
The idea of growing software, instead of building it, has persisted (and grown) in the last three decades. It has even culminated in books with exactly that same title: Growing Software (Louis Testa) and Growing Better Software (Marc Brevoort). I haven't read these books myself (yet), but I'm sure I will. After all, now that I have built a brand new book case, I have plenty of space to grow my collection of books.
When it comes to managing teams the terminology is again not properly applied. Managers usually talk about team building while they should be talking about growing their teams instead. In Peopleware, another timeless classic by Tom DeMarco and Timothy Lister, I found this about it:
We stopped talking about building teams, and talked instead of growing them. The agricultural image seemed right. Agriculture isn't entirely controllable. You enrich the soil, you plant seeds, you water according to the latest theory, and you hold your breath. You just might get a crop. You might not. If it all comes up roses, you'll feel fine, but next year you'll be sweating it out again. That's pretty close to how team formation works.
Again, my thinking turns out to be devoid of originality. These software development veterans already saw things correctly 22 years ago. And, since then, the agricultural metaphor has been used many times to explain how to manage people. In Gardening and Management: What They Have in Common Dan Bobinski draws his own interesting parallels:
In the same way that we can't make a seed grow, a manager cannot motivate people.
A gardener selects plants appropriate to the purpose and location of the garden. [...] In the same way, managers need to be aware of the mission and vision of the workplace and select employees that will subscribe to that vision.
In a garden, weeds can grow so big that they use up a lot of soil nutrients and water, thus diminishing what's available for the plant. In the workplace, weeds represent rumors and non-productive attitudes that deplete energy away from the real work that must be done.
And the analogies don't stop there. Allow me to try and add three more:
- Living systems grow fast in the beginning, and then reach a level of maturity. Mature systems don't need to be looked after as often as the young systems. Mature software has finished growing, and an occasional check-up is sufficient to keep things running smoothly. And mature teams don't need to be looked after that much either. They are experienced enough to fix most of their own problems.
- When a garden is not being managed, it will simply keep growing, but in another direction than what was intended. (It's a good thing I don't have a garden in Rotterdam, because it wouldn't be a pretty one. I hate gardening.) It's the same with software systems and teams. If you don't manage them, they will grow in a direction that was never planned. And the result might not be as pretty as you had hoped for.
- And finally, many growing systems have a certain life expectancy. They have a tendency to wither away and die. There's nothing wrong with that. It is part of nature. When living systems get old, more and more time and energy are needed to maintain them. Gardeners know that there comes a time to replace the old with the new, by digging out the old, roots and all, throwing it on the compost heap, and making room for new seeds to grow.
Developers and managers have a lot in common. We are all gardeners. We seed, feed, and nurture our systems. We know young systems need more care than mature ones. We weed out everything that draws energy away from our healthy growing systems, and, when the time has come, we are ready to replace the old with the new.
And that was the 258th article that I wrote (or built), while my blog keeps growing and growing...
(pictures by WordRidden and John Weiss)
Twitter -
Subscribe -
Newsletter -
Bookmarks
Latest, greatest and favoritest posts:
Leader vs. Ruler: Which One Are You?
Optimize Communication, Throw the Boss Out
Simple vs. Complicated vs. Complex vs. Chaotic
