Tiago Fernandes

thoughts

Software development: Architecture vs Gardening

The computer science and software engineering are some of the youngest of the sciences and engineering branches.

Creating all the new abstractions made us borrowing terms from multiple areas.

The fact that software does not abide by the physical rules that guided most of the other sciences made the creators seek common analogies to describe these new realities.

These Grey beards also took multiple language liberties in order to explain the complex abstractions. e.g. Parent killing children 😬 ...processes 😮‍💨. Other occasions, they just amuse themselves by using plain puns, typos, or play on words. e.g. 'creat', the recursive acronyms as GNU (GNU's not UNIX).

Making a name for yourself

When the industry around it matured, there was a need to vindicate your work as important as other engineering or sciences. Analogies to building and construction were present so it was only a matter of time for the industry to incorporate construction terms into their "foundations".

As systems grew and moved away from single purpose software pieces into complex, multi team systems, and with that the need for organisation and some order. The manager of that order was, same as in a construction site, refered as the architect.

The nature of software

Software is not immutable

From its conception, and going through the MVP to a stable phase and further iterations, the only constant is the fact that software is always changing. Software faces product requirements changes, database schema changes, security updates, refactors.

Entropy

Software development follows the laws of nature. Its quality gradually declines and consequently entropy arises. This entropy goes by many shapes and forms: technical debt, unintended complexity, lack of documentation, half finished implementations that create confusion and misalignment on future development patterns.

If these are left unattended we end up with the famous "spaghetti codebase", "the big ball of mud". This blend of everything into a paste also defined as entropy.

Software is not a building

The way that we transmit our job people outside our realm is that we're builders, architects. The assumption is that we build and besides little fixer uppers buildings are built. Right?

Does software development "ends" as the construction of a building ends? After its construction a building might need a window to be fixed or a new coat of paint every now and then.

But most definitely no builder would see as a feasible proposition moving the 3rd floor to a different lot whilst the lift must keep serving the 3rd floor after the 2nd and before the 4th.

Is it a garden, then?

Yes! (kinda).

Software rots if not properly maintained

As an unattended garden, an unmaintained system will rot. It will have security issues, bugs and exploits would be eventually discovered, non up to date APIs will stop working and fail to fulfil its purpose.

Software needs care

When adding a new feature you don't consider the implications, and don't perform that needed refactor, it will create tech debt. Similar as weeds or branches on a tree that are not properly prune to allow the tree's growth and other plants' growth. You keep avoid this and you won't be able to enter your garden, and when you need to, you'll need a weedwacker to remove all of it to start over.

You need to care for it all the time. You love the results, same way that you love to work on a simple, clear, clean codebase. It makes your day.

Software evolves

New software requirements arise, we need to adapt the current system to accomodate those needs. Same way, when we need to plant a new crop we need to accomodate the soil and their surroundings to best fit them.

Is it gardening, really?

Ok, hear me out. Gardening it's not a perfect analogy. The take to this argument is to

_______
published: 04/06/2025, 18:28:36 CEST
updated: 04/06/2025, 19:56:17 CEST

rss