Recently I've been reading The Pragmatic Programmer (for the second time 😁), and I came to one analogy that struck me hard, and changed my whole thinking about software development.
In the chapter 6, called While you are coding, page 184, the author says:
Unfortunately, the most common metaphor for software development is building construction. [...] Rather than construction, software is more like gardening--it is more organic than concrete.[...] You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed.
This just made me realize the contradictions I've been living with and the need to come to terms with software development and its real lifecycle. More often than not, software is not just written and that's it. It evolves over time as needs arise. The code you wrote 6 months ago might be rewritten, and that's fine. Dependencies update, your software changes due to it. Et cetera.
This may not be news to you as a software developer, but an unpleasant quantity of non-technical people who works with developers, may not understand this and think this is like building construction (as I did before). This is your pitch for them:
Software is not static. Software is alive.
Thanks for reading.
Top comments (9)
Woohoo! I came to love this metaphor independently. It made me happy to hear it had been validated by some other really smart people.
Organic terms really make sense in this field. There's simply too much going on in any system to try to control it like we would a building via "architecture".
I think software has changed a lot over the years too. For instance, in the 1950s and 1960s, typically software was written in machine code for a specific mainframe hardware architecture. Once it was in production, it was unlikely to undergo many changes. Even making a small change was a huge pain.
Then, a decade or so later, the company might buy a new mainframe, with a totally different architecture. So now they had to rewrite the software completely from scratch. That's probably a more apt comparison to how a bridge or a building is constructed.
Over time, the advent of compilers, operating systems, and hardware standardization allowed software to be re-used. Software became increasingly "soft." A piece of code could be re-compiled for new hardware, and its calls into the OS and standard library would still work. That way, software didn't have to be re-written from scratch anymore. It could just be updated with new features.
Nowadays, with online updates, software really is like a living organism that is continually changing and evolving.
I think that the misconception of this sometimes leads to many of the problems that we have regarding management expectations.
For example: if people could see the software in organic terms, maybe they could see development estimations like "How much will take this tree to grow if you do all that you have to do?" instead of "How much will take you to build this Wall?".
The first one even when you think you have everything cover, your results can be affected by environmental factors like illumination, weather, quality of the ground (legacy code), etc. However, the second one, when you have the right expertise, build a wall almost ever will be the same.
Nice post, Socrates.
No, indeed, software is alive; it grows, but it can rot as well.
And sometimes it must die.
Yeah, but be aware that gardening is not always such a romantic thing. There is bad weather, hail, thunderstorms, plant diseases and animals that eat your crops. And you can do little about these things, even if you work hard.
I agree. In software, you also take risks. Things that deeply affect your software can happen, which you cannot control or can do little about it.
For example, a vulnerability discovered in the platform where your software runs (e.g.: Meltdown, Spectre), or the server where your webapp runs gets hacked and your data gets compromised (which is similar to the situation where animals eat your crops).
Lovely metaphor
Quite interesting opinion! I absolutely love gardening, especially indoor gardening! There's something so satisfying about nurturing a plant from a tiny seed to a fully grown plant. And with the help of Primal Grow Gear's Complete Grow Kits primalgrowgear.com/product-categor... it's never been easier. Their kits come with everything you need to get started, from the grow tent to the lights and ventilation. Plus, their customer service is top-notch, always ready to answer any questions I have. If you're thinking about starting a garden, I highly recommend giving indoor gardening a try with Primal Grow Gear's Complete Grow Kits.
I like the analogy of software engineering and gardening. I believe in the power of analogies in conceptualizing abstract problems and I think it's useful to be able to compare two fields (excuse the pun) and ask yourself, "How are these two different, and how are they similar?"
Comparing software to construction has been very useful in the past when I communicate technical work to non-technical people. In my experience, comparing a piece of software to a building -- either a building that's in the process of being erected or, say, a derelict building that's being repaired -- is a very tangible, visual and intuitive way to communicate progress.
It's also a good way to explain the intricacies of software development. I don't know much about how buildings are actually constructed, but I can compare framework code to the building's foundation, or inter-process communication to the pipes or electric wiring in a house, etc.
I tend to prefer the building analogy a bit more, because one of the big disconnects I've found among people who don't understand tech and people who do, is that the former group tends to assume that things are a lot more automatic than they really are. A plant may be able to grow on its own with little supervision, but a building needs to be consciously built and then consistently repaired and maintained if you want to keep it standing.
For instance, I have an app I develop on the side, when I have free time. Sometimes I don't touch it for months, and usually, when I return to my codebase after a few weeks of absence, the chances are good that I spend a bit of time updating dependencies, rebuilding a cache, fixing a permission problem that edible mushroom growing kit crept in when another piece of software was installed, etc.