As software projects mature, the challenge is not only managing technical debt, but also preserving the understanding behind the decisions that shaped the code in the first place.
A recent discussion about Joomla’s calendar field reminded me how easy it is to misunderstand complexity in long-lived software.
At first glance, the code looked unnecessarily complicated. There were conditionals, exceptions, and handling that seemed excessive for something as simple as displaying a time.
The obvious reaction was: surely this could be simplified.
Except there was a reason it existed.
The issue was RTL (right-to-left) language support. Time is normally written as hh:mm, but naïve RTL transformations can end up displaying it as mm:hh. That problem is relatively easy to spot when using familiar numerals. It becomes much harder when those numbers are rendered in scripts such as Farsi or Chinese.
Suddenly, the “messy” code no longer looked so unnecessary.
It was solving a problem most developers reading the code would never encounter themselves.
And that is where the tension between technical debt and institutional memory begins.
The Assumption That Complexity Is Wrong
In software development, especially in mature projects, there is a natural tendency to look at older code and see technical debt.
Sometimes that assessment is correct. Over time, every project accumulates compromises, shortcuts, compatibility layers, and outdated approaches that need to be revisited.
Joomla is no exception. After more than twenty years of development, there are inevitably parts of the codebase shaped by old hosting limitations, browser inconsistencies, evolving PHP standards, and changing architectural ideas.
Reducing technical debt is important. Mature software cannot survive otherwise.
But there is another possibility that is often overlooked:
The complexity may exist for a reason.
Institutional Memory
That is where institutional memory matters.
Institutional memory is the accumulated understanding of why things were done the way they were. Not just what the code does, but what problem it was solving at the time.
In open source projects, this knowledge often lives in discussions, issue trackers, pull requests, and the memories of long-term contributors.
And in volunteer-driven projects like Joomla, people naturally move on over time.
When they do, context disappears.
The code remains, but the reasoning behind it slowly fades away.
Years later, someone encounters a strange workaround or an overly defensive piece of logic and assumes it is simply bad code.
Sometimes it is.
Sometimes it is institutional memory encoded in PHP.
The Multilingual Reality
Another area where this becomes obvious is localisation.
Pluralisation looks simple if your primary language is English. Most developers instinctively think in terms of singular and plural.
But languages do not all work the same way.
Russian uses four plural categories: one, few, many, and other.
Welsh uses six: zero, one, two, few, many, and other.
Joomla supports all of them.
That is why developers encounter language strings like this:
COM_EXAMPLE_ITEMS_0="No items"
COM_EXAMPLE_ITEMS_1="One item"
COM_EXAMPLE_ITEMS_FEW="%d items"
COM_EXAMPLE_ITEMS_MANY="%d items"
COM_EXAMPLE_ITEMS_OTHER="%d items"
Used in code like this:
echo Text::plural('COM_EXAMPLE_ITEMS', $count);
To someone only thinking in English, this can look repetitive or unnecessarily complicated.
But that complexity is what allows Joomla to work correctly across languages with very different grammatical rules.
Remove or simplify it without understanding why it exists, and you are not improving the software—you are breaking internationalisation for users you may never even think about during development.
Long-Lived Projects Carry History
One of the realities of maintaining a project like Joomla is that the codebase contains years of accumulated experience.
Some of that experience is visible in documentation. Much of it is not.
Long-term contributors often remember why a workaround was introduced, why a particular implementation was chosen, or which edge case caused problems years earlier.
That knowledge is valuable precisely because it prevents projects from repeatedly solving the same problems.
Without it, every unusual piece of code starts to look like a candidate for cleanup.
And sometimes cleanup quietly becomes regression.
More Than Just Code
This is not an argument against refactoring or modernisation. Joomla has survived because it has continuously evolved.
But successful evolution requires understanding as well as improvement.
Not every awkward-looking solution is technical debt. Sometimes it is simply the visible result of years spent making software work reliably across different languages, browsers, hosting environments, and user expectations.
That context matters.
A Final Thought
Reducing technical debt is important, but so is preserving the understanding that explains why the software works the way it does.
Because while code can always be rewritten, lost context is often much harder to recover.
