A good senior Software Engineer fullfills the roles of a writer, an engineer and a gardener. What are these metaphors and what do they speak of?
As a writer, they have to weigh every word, every sentence and every paragraph.
As an engineer, they have to consider the cost, the structure and the architecture.
And as a gardener, they need to consider the future prospects of the project, how the software grows and how much weed has grown over time.
I consider each of these perspectives equally valid metaphors for software. All have limitations, drawbacks and benefits. However, together they can speak loudly about how we should consider Software Development. So what are these metaphors and what do they speak to?
The writing metaphor
Write code for the reader, not the writer. You could easily replace code with another word and the advice could equally apply to a distinguished author. But it goes further. Being a writer comes with inherent tradeoffs.
software engineers are authors
Writing something elegant could deter from its accessibility. For example, consider the previous sentence. If you don’t know the words “elegant” or “accessibility”, it’s hard to read. So writing harder words makes the text harder to read.
The same goes for code: using an obscure language feature makes your code harder to read. However, jargon is good actually! It’s what DHH calls “Conceptual Compression”: Because you compress a complex system into one concept, it makes taking further steps simpler.
In that way, coding is like philosophy, which is mostly writing, which is mostly thinking clearly. You are modelling the world. As a writer with words, as a coder with code.
The engineer metaphor
Software engineers are engineers, that one is the easiest. I don’t have to make this point again, because other people make it very compellingly.
Cost vs Time vs Quality
The real of the standard engineering tradeoffs is: Costs vs Time vs Quality. We see this tradeoff in every engineering domain and software isn’t different. However, because software is so abstract to so many people, we can use this metaphor more often.
Instead of your issue becoming an abstract “programmer says no”, you can use the engineer metaphor to make a problem visceral. For example, I once used the description: “What you are asking me is to take a stone in the middle of the wall and put it on top.” The project manager in this case understood immediately.
The metaphor works equally as well when describing the “DIY vs professional”-tradeoff. DIY being do-it-yourself here. Nobody should object to a DIY shed in your garden. And everyone should object to a DIY skyscraper. The problem with some DIY sheds in software is that they turn into skyscrapers over time. If the underlying methodology doesn’t improve, you get very unstable buildings[1]. And as long as this isn’t acknowledged by leadership, you get very jaded engineers. Because those engineers can see the DIY mess for what it is.
The gardening metaphor
I’ve been familiar with the meme “boyscout principle”. Boyscout principle means that you leave the software better than you found it. The gardening metaphor works on more levels. The one difference from a real garden and a software garden is this: if software isn’t worked on, the garden is frozen.
With this in mind, the gardening metaphor works as follows:
- Features of the garden are features in software.
- Technical debt is like weeds in the garden.
- Planned gardens will not work without maintenance, and it’s better to let them grow organically with a vision. (Agile)
- Adding new features to a garden without ever weeding, will eventually make your garden a complete mess.
- A small garden can do without signs, but a park needs maps. The same is true for software documentation.
- The complexity grows exponentially with size and scope.
- Beauty is in the eye of the beholder.
- When you plant the first seed, you will never know what it will become.
I think the garden metaphor is especially useful for explaining agile. Agile was a giant breakthrough and it’s where software is distinct from other engineering disciplines.
Conclusion
These metaphors help you think and help explain software to a layperson. I believe we have a responsibility to make software accessible to everyone. And that begins by having language that bridges the gap between jargon and broader speech.