DEV Community: Fernando Fornieles

Rapid Development of a Weather Dashboard and API Without AI

Fernando Fornieles — Mon, 06 Apr 2026 18:35:55 +0000

Having a weather station is good, having a dashboard and a history of meteorological data is better. So, I decided to implement a web application.

The challenge was to see how fast the development could be using only the bundles and commands provided by the PHP Symfony framework.

The project includes the following:

A Dashboard to see the current weather data and some graphs to display the evolution over time.
An API to allow the weather station to send data
An admin area to manage the weather data

Here, the source code of the project.

The setup

Preparing everything to be ready to start implementing anything is always the most annoying part, at least for me.

Luckily I have a MariaDB and an Apache server running on my PC with, more or less, the same configuration as my "production" server, a Raspberry Pi 5 that I use to self-host my private cloud.

Thanks to this, I only had to create the database for the project and download the basic Symfony project using the amazing Symfony CLI tool.

$> symfony new weatherdashboard --webapp

Once done I installed the Symfony apache-pack for better integration of the project with the Apache web server:

$> composer require symfony/apache-pack

I also installed the Doctrine Fixtures bundle to easily create some initial data, like a default user for the admin area.

$> composer require orm-fixtures --dev

The last setup step was to configure the database connection in the Symfony .env file.

Everything was ready to start working on the project!

The Meteorological Data Admin

I wanted to manage the weather data received from the station. Why? Simply to be able to delete some weird data that can be received and also for testing purposes.

The first step was to create the meteorological data entity to store the weather information.

The MeteoData entity should have the following attributes:

deviceTemperature: float
temperature: float
humidity: float
relativeHumidity: float
dewpoint: float
lux: float
pressure: float

Creating the entity was as easy as executing the following command:

$> bin/console make:entity

The entity is nothing if the database table it maps doesn't exist. Creating the table in the database is as simple as this:

$> bin/console make:migration
$> bin/console doctrine:migrations:migrate

The last step was to create all the code to manage the meteorological data with this "magic spell":

$> bin/console make:crud

Without typing any code, just with a few commands, I had the Meteorological Data Admin complete and ready to use.

Securing Access to the Meteorological Data Admin

An Admin area needs to be private, so I secured access to the Meteorological Data Admin.

The first thing to do was to create the User entity:

$> bin/console make:user

Then, as before, I ran again the migration commands to create the table in the database.

To create the admin user I decided to use the Doctrine Fixtures bundle, a useful tool to insert default or initial needed data into the database.

To do this I had to implement the UserFixtures class manually to create the admin user. There is no command, or at least I don't know it, to "automagically" create a default admin user.

Once done, using the following command, the admin user was loaded into the database.

$> bin/console doctrine:fixtures:load --append --group=UserFixtures

To access the admin area, a login form is required. Creating it is really easy:

$> bin/console make:auth

The last step was manual again but simple. I just added the following to the "access_control" section of the "config/packages/security.yaml".

- { path: ^/meteo, roles: ROLE_USER }

The "meteo" path was secured while the dashboard on the home page remained public.

Creating the Dashboard HTML template

Everything in this Weather Station project was implemented without AI. But, as I'm not an expert in web design, I made an exception here and asked ChatGPT to create an HTML dashboard to display the current weather data.

With this static HTML, I was able to create the Twig base template of the project and the dashboard page.

Implementing the API endpoint

To connect the Weather Station with this web application, an API was required. To do this I installed the Symfony API Platform bundle.

$> composer require api-platform/core

The magic spell ends by adding this annotation in the MeteoData entity:

#[ApiResource]

What? That was all? Yes, that was all it took to have an API ready to receive data from the Weather Station. As simple as that.

Securing the Access to the API

This webapp and the weather station both run in my local home network. But I wanted to see how two different ways of authentication, user session and stateless JWT token, could coexist. Also to have some fun, of course :-)

I installed this bundle to secure the API using a JWT token.

$> composer require lexik/jwt-authentication-bundle

Then I generated the SSL keys required to create valid JWT tokens:

$> bin/console lexik:jwt:generate-keypair

A manual step was required to configure the station user. As the station is a machine and not a regular user I decided to use a simple approach creating a in-memory configuration.

    api_user_provider:
        memory:                
            users:
                station: { password: '%env(METEO_PASSWORD)%', roles: [ 'ROLE_API' ] }

Now, I just needed to generate the JWT token for the station user to see if it worked:

bin/console lexik:jwt:generate-token station --user-class=Symfony\\Component\\Security\\Core\\User\\InMemoryUser

But then I got stuck... When trying to use the API it returned the following error:

ERROR 500: Session was used while the request was declared stateless.

I read the Symfony documentation about how to have two types of authentication in the same project, I googled it, I searched forums, I tried everything to avoid the use of AI.

My "spider sense" was warning me about what could be the problem, but I decided to ignore it. You know, sometimes you ignore this little voice in your head that is telling you the right thing. And then I gave in, I didn't want to, but I ended up asking the AI...

What was the AI response? Exactly what my intuition was telling me :-D. It was the order of the security firewalls configuration. I had first the user authentication, that requires a session, and then the API.

Changing the order and putting the API authentication first fixed the issue. Problem solved with a huge dumb face xD.

Conclusion

The purpose of a framework is to allow developers to focus on the real problem, the third party libraries or bundles exist to avoid reinventing the wheel.

This is not a surprise, of course, but in these times where AI seems the answer to developing fast, I wanted to prove to myself that it is possible to do it as fast as with AI.

And I think that I achieved the goal, in about 16 hours of work I was able to finish the Dashboard, the admin area and the API.

In the next article I will try to explain how I replicated the whole Weather Station System using AI.

Reading Data from Weather Sensors with Python

Fernando Fornieles — Sun, 29 Mar 2026 18:18:50 +0000

Apart from building a weather station, another thing I had been wanting to do for a long time was to learn Python. With this Weather Station project I satisfied both :-)

Check the source code of this project in Codeberg.

Learning the Pimoroni's WeatherHAT library

The first thing I did, after having everything installed, was to learn how the Pimoroni's WeatherHAT library works in order to:

Read the weather data from the sensors
Display the weather data in the WeatherHAT's screen

So I opened an SSH connection and started playing!

Apart from being my first steps with Python what I learned about the library was:

It is necessary to call the "update" method of the sensor before getting the weather readings
The first reading is "crap", it is necessary to perform an initial update and wait a few seconds before getting good reading values.
There are two attributes for temperature: device_temperature and temperature
The temperature attribute is calculated by applying a default offset of 7.5ºC to the device_temperature reading.

Calibrating the Temperature

The first thing I focused on was to properly calibrate the temperature. For this I spent some days gathering temperature data from the sensor and from another nearby weather station at the same time, taking readings every hour.

What I noticed was that the difference between both sensors wasn't a fixed value. The readings from the WeatherHAT's sensor were always between 12ºC and 16ºC higher than those from the nearby station.

So instead of applying a fixed offset I tried a linear regression. I created a class to calculate the offset based on a given device_temperature value.

In the future I could find a better way to calculate the offset. That is why I created a TemperatureOffsetInterface.

class LinearRegressionOffset(TemperatureOffsetInterface):
    def __init__(self, config):
        self.a = 0
        self.b = 0
        self.config = config
        self.doLinearRegression()        

    def getOffset(self, x):
        offset = (self.b * x) + self.a        
        return offset

    def doLinearRegression(self):
        x = self.config['data']['x'].split(",")
        y = self.config['data']['y'].split(",")        

        x = list(map(float, x))
        y = list(map(float, y))       

        medianX = statistics.median(x)
        medianY = statistics.median(y)
        numSum = 0
        denSum = 0

        for index, xValue in enumerate(x):
            numSum = numSum + (xValue - medianX) * (y[index] - medianY)
            denSum = denSum + ((xValue - medianX) * (xValue - medianX))

        self.b = numSum / denSum
        self.a = medianY - (self.b * medianX)

I could have used a Python library to perform the linear regression but, remember, the goal of this project was to learn Python ;-).

Decoupling From The Hardware

Having solved the calibration of the temperature sensor it was time to start coding the reading system.

The process should run periodically, for example every 5 minutes. On each iteration the system should read the data from the sensor, apply the temperature offset, display the data on the screen and send it to an external service.

I work on my own PC, as it is more comfortable than coding directly in the Pi. That is why I created some mocks to simulate access to the WeatherHAT hardware.

This way I could code the main algorithm decoupled from the hardware.

sensor = factory.createSensor()
display = factory.createDisplay()

Once the main algorithm was done I simply had to code the hardware-specific parts. I had to upload each change to the Pi but using the examples provided by Pimoroni it was more or less easy to get the data from the sensor and show it in the WeatherHAT screen.

Sending The Data To An External Service

I wanted to see the current temperature from anywhere and also store the readings in order to generate statistic from the weather data.

So the next step was to send the data to an external service. As I hadn't yet implemented my Weather Data Webapp, I started sending the data to Adafruit. I created a dashboard to see current data and also a graph to easily compare the temperature readings with the nearby station. This way I could check the quality of the linear regression.

I created an ConnectorInterface to first create the Adafruit connector and later the implementation to send the weather data to my Weather Data Webapp.

class ConnectorInterface:
    def send(self, WeatherData):
        pass

I also created a MockConnector to avoid sending bad data while working on the main flow of the algorithm.

Implementing An Abstract Factory

Everything was working fine, but changing which implementations to use while testing the system locally (mock) and in "production" (on the Pi) was a bit messy.

To simplify the mode selection I applied the Abstract Factory Pattern. This way, with a single configuration setting, I could load the right set of components (Sensor, Display and Connector).

class SystemFactoryInterface:

    def createDisplay(self) -> DisplayInterface:
        pass

    def createConnector(self, config) -> ConnectorInterface:
        pass

    def createSensor(self, config) -> SensorInterface:
        pass

Conclusion

I enjoyed this part a lot. Learn Python, read the data from the sensor, calibrate the temperature, apply some design patterns, ... It brought back the feeling I had when I first started learning to program.

Maybe because it is a project that is really different to the ones I'm more used to develop, maybe because it mixes different things or maybe both :-).

In the next article I'll try to explain the implementation of the Weather Data Webapp. This time with PHP and Symfony, a language and a framework that I'm more used to work with.

Building a Weather Station Using an Old Raspberry Pi

Fernando Fornieles — Mon, 23 Mar 2026 17:20:41 +0000

For a long time I wanted to build a weather station at home because I like meteorology and for the fun of doing it. So I decided to stop waiting and just do it :-)

Connecting the sensors

I wanted something easy to attach to my old Pi, a Raspberry Pi 2 model B+, that would let me easily read the data from the sensors. The Pimoron's Weather HAT fit perfectly with what I wanted:

Just connect it to the GPIO interface
Download and install the Python library provided by Pimoroni

Pimoroni has a good tutorial that helps you build it and solve some of the common issues. There are also other articles from the community that are really helpful.

One good thing about this Weather HAT is that it is possible to connect a wind and a rain gauge. I don't have so much space in my balcony so I didn't get these sensors, but it is something that I would like to have in the future.

There is a good set of examples to read the data from the sensors and display it available in the Weather HAT's GitHub.

The Challenges

But it has an important downside, the sensor temperature is affected by the Pi's CPU as it is very close to the board. So the temperature needs to be compensated, which is not as simple as applying a fixed offset as stated in the Pimoroni's tutorial. Instead I tried to apply a linear regression by obtaining the temperature from another weather station that, luckily, is close to my home.

Apart of installing the Weather HAT and reading the data from the sensors, the most important challenge was finding the best place for it in the balcony and how to isolate it from the external conditions, while at the same time allowing enough ventilation to avoid heat accumulation inside.

Protecting the Weather Station from the Environment

Once I had the Weather HAT installed I used the following materials to place the station on the balcony:

A transparent plastic lunchbox
A base enclosure for the Pi
Some adhesive protectors for furniture
Some glue

Maybe a lunchbox is not the best solution but using a Stevenson Screen could be a bit overkill.

I used the furniture protectors to separate a little bit the Pi from the back of the lunchbox, this way the sensor has some additional separation from the wall.

At the same time I made some holes in the lunchbox to let the air flow inside to cool the Pi. I made some of the holes on the side where the sensors are located and the others on a lateral.

A few days later I noticed that, due to that holes, on windy days the measure of the temperature sensor can provide values a little bit lower than the real one. But I prefer this to having the Pi without this air cooling. I don't have the perfect materials, so I can't expect to have the perfect measures.

Calibrating The Temperature Sensor

As I mentioned above the readings of the temperature sensor need to be compensated as it is close to the Pi's CPU.

The Pimoroni Python library for the Weather HAT has an attribute to set an offset that is applied to the device temperature measure. So I tried comparing the Weather HAT sensor values with the temperature provided by a nearby weather station.

What I noticed was that the offset to apply can't be a fixed value. The difference between the real temperature and the values provided by the Weather HAT was always between 12º and 16º.

To solve this I create a small script to get temperature data from both stations at the same time. With this series of data I was able to create a linear regresssion model to calculate the offset that should be applied to the HAT's device temperature reading.

It is not still perfect. When the device temperature is close to 30º the difference is quite high, but for the moment, it seems a little bit better than applying a fixed offset as you can see below.

In the next article I'll describe my Python learnings implementing the software to gather the measures, display it and sending it to an external system.

A Home Weather Monitoring System Built Without AI

Fernando Fornieles — Thu, 19 Mar 2026 22:56:25 +0000

Coding without using AI may seem revolutionary nowadays but what I wanted was simply to learn Python and enjoy the act of coding with my own hands.

So I built a Home Weather Monitoring System with the following components:

A weather station
A software to read the sensor ~~lectures~~ measures
A web application to view the Weather Data

The Weather Station

I wanted something easy to build, so I recycled an old Raspberry Pi to attach a Pimoroni's Weather HAT to it. This board has sensors to measure temperature, pressure, humidity and luminosity and a little screen to display the weather data.

For reading the sensors and display the info on the screen, Pimoroni provides a Python library and some examples of how to use it. It is really easy and a good starting point to experiment.

The Sensor Reader Software

Once the Weather HAT is installed and having played with the Python library, it's time to write the software to do what you need.

In my case I wanted to display the reading on the screen to see them directly. The other thing I wanted was to send the weather data to a web application in order to check the current values from anywhere and keep a history of the data.

But since it is more comfortable for me to code on my PC instead of doing it directly on the Pi, I had to create a mock for the sensor reader and the screen.

This was a good opportunity to achieve my goal of learning Python more in depth by creating interfaces and applying design patterns :-)

The Weather Data Web Application

As mentioned above, I wanted a web application to store the weather history and show the current weather values from anywhere.

To build this I choose PHP and Symfony as a framework. As I have experience with both, the challenge was to see how fast I can implement this web application using only the productivity tools provided by the framework and its bundles.

The web application has the following components:

An API endpoint to receive the weather data, secured by a JWT token
A front page to show the current data as well as some statistics and evolution graphs
A private backoffice to manage the weather data, secured by a username and password.

This is the first article of a series where I will share, for those that may find this interesting, my learnings and how I enjoy building my personal Home Weather Monitoring System.

Interesting article I've read today about the repeated promise of eliminating programmers in the history of software development. https://www.ivanturkovic.com/2026/01/22/history-software-simplification-cobol-ai-hype/

Fernando Fornieles — Tue, 03 Mar 2026 15:21:32 +0000

The Eternal Promise: A History of Attempts to Eliminate Programmers

From COBOL in the 1960s to AI in the 2020s, every generation promises to eliminate programmers. Explore the recurring cycles of software simplification hype.

ivanturkovic.com

Embrace Software Entropy, you can't avoid it

Fernando Fornieles — Mon, 09 Feb 2026 07:00:00 +0000

The wise programmer is told about Tao and follows it. The average programmer is told about Tao and searches for it. The foolish programmer is told about Tao and laughs at it. If it were not for laughter, there would be no Tao.
The highest sounds are hardest to hear. Going forward is a way to retreat. Great talent shows itself late in life. Even a perfect program still has bugs.

— Geoffrey James (The Tao of Programming)

At the beginning of any project there are a lot of decisions to be made. What is the best approach to solve the problem? What is the architecture style that fits best? Is the design of the solution accurate? Are we missing something?

Even before starting to code there are a lot of things to think about. Should I create an interface or an abstract class? This design pattern really fits here? How can I approach this corner case?

This usually tends us to fall into the Analysis Paralysis trap. We want to take perfect decisions, to design the most suitable solution for the problem, to write the best maintainable code, ... But there is no a perfect decision, no perfect technology, no perfect code, ... Because from that initial moment, entropy will only increase throughout the whole life of the project. This fact will make you question the decisions made in the past.

Software entropy, the level of chaos in any software system, is not only about the accidental complexity you may add in form of technical debt, lack of understanding or experience, over-engineering or whatever other reason. It is also about the essential complexity of the domain and its requirements which introduces its own level of entropy.

You may write the best code, take the best technological decisions, have 0% of technical debt, ... but the software entropy of your project will get higher and higher any time you implement a new feature, solve a bug or make an "innocent" change in a single line. All of these may increase entropy even being perfectly implemented.

Software entropy is unavoidable. The more changes we introduce the more entropy we create, the faster we introduce changes the faster the entropy grows. It can be reduced, or at least mitigated, by refactoring the code, applying best practices and trying to avoid accidental complexity. But the long-term trend for entropy will be to increase.

Taking time to consider different options is the way to ensure that a solution is a good one, maybe not the best but a good one. Just stop the Analysis Paralysis, take a decision and after that flow with the entropy. :-)

Interesting article about our ego as developers I read the other day. https://shiftmag.dev/developers-your-ego-is-the-real-bug-in-the-system-7657/

Fernando Fornieles — Wed, 04 Feb 2026 11:31:18 +0000

What is egoless programming?

How ego-driven decisions cause software teams to fail, and how egoless development builds trust, better collaboration, and stronger products.

shiftmag.dev

Once upon a time when I built AI agents…: A grandpa story

Fernando Fornieles — Tue, 20 Jan 2026 13:30:00 +0000

“Most of the time, when searching for information about anything on Internet, you get lots of results that are mostly not exactly what you were looking for. A search through these results is needed until you find what you really need, wasting time that could be dedicated to something else. The purpose of the project is to build a mechanism that applying Artificial Intelligence techniques, would create agents capable of showing only relevant information to the user.”

It is an excerpt from my final degree project, “Content Personalization and Subjectivity Capture using Case-Based Reasoning and Fuzzy Logic techniques”, presented in 2001 at the University of Girona.

The goal was to build a system able to customize content, based on user preferences, trying to catch their subjectivity. That means not only capturing what things a person may like but also in which degree.

Agents Inspired, a spin-off company founded by my project supervisor and other teachers, had the same goal. Having the opportunity to work on something really close to my degree project was something that I couldn’t pass up. So when my supervisor told me if I would like to join I had no doubt!

During this intense period, I learned an important thing about AI: it is as “simple” as applying maths to a set of data. A system with a well categorized set of data and a good mathematical model should be able to provide personalized content to the user.

One of the formulas to calculate the distance between profiles that was in my final degree project. Please, don’t make me explain it, I lost my memory about it!

But this is just one part of the story. The real challenge in any AI system is the processing power needed to be able to perform these calculations. This problem can be mitigated by applying better algorithms and fine-tuning the databases, as we tried in our old AI system, but at a large scale this is not enough.

The growing number of AI Data Centers around the world, which are causing a huge environmental impact, will probably set the limit of what we can achieve with AI. It doesn’t matter how good the mathematical model is or how good the quality of the dataset can be. AI power requirements will push it to the limit of scaling.

Dr. Sbaitso (1992), one of the ancestors of ChatGPT

Some years later, after leaving the company, I read about the RSS format and I immediatly saw the potential to apply AI to create an agent that, reading information from several feeds and learning from my interactions, could create some sort of a personalized “newspaper” by leveraging the categorization feature of RSS and analyzing the words from each entry.

So I built a Java Swing application that worked nicely. But only at the beginning… I quickly realize that the more things the system learned, the less it knew about me. This was due because, like anyone else, I have several interests and as the system widened its knowledge about me the distribution of probabilities became so similar that it couldn’t tell what was actually interesting.

This was another important lesson learned about AI and data: more data doesn’t necessarily mean better results. But there is another important issue, AI as a recommendation system is limited by what it knows about you. What about those things that are far from your taste profile but you may like? How can you broaden your musical taste, for example, if the system never recommends you music genres that you have never listened to?

Apart from this, during my professional career and also for personal interest, I took courses and trainings about AI, Machine Learning, Natural Language Processing, …

This personal experience doesn’t make me an AI expert, that is far beyond my capabilities, but I hope it provides me with enough judgement to avoid the hype around it. My genuine interest is because I truly believe that we can find use cases where this amazing tool can be useful but not in the way that is currently presented.

Current AI is just a “wordjoiner”, it can’t reason or understand anything, it just joins words that look good together. So that is why It is hard for me to understand why people blindly trust in this systems when the result is totally impredictible.

Cover Image is from the film War Games (1983) where an AI called Joshua could provoke a global thermonuclear war

AI: The Danger of Endogamic Programming

Fernando Fornieles — Mon, 19 Jan 2026 08:00:00 +0000

There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, “What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure.”

— Geoffrey James (The Tao of Programming)

Learning to program in any language is relatively easy. What is not easy is developing analytical skills to structure it properly. The solution, however, is simple: face new problems, write more code, fail, and apply what you learn to solve even more problems.

As developers gain experience, they spend more time thinking about how to solve a problem than writing code. This natural progression leads them closer to the Tao of Programming ;-), giving them the judgment needed to choose the right techniques and tools. AI is one such tool, powerful and useful when used wisely. But to use AI wisely, one must be close to the Tao.

If a novice developer relies blindly on AI instead of making the effort to find solutions themselves, they risk slowing their growth. In the end, they might have working code, but without understanding why it works. This lack of understanding can lead to massive technical debt.

However, the risks go beyond technical debt. If AI is used to generate most of the code without being fed with new ideas or creative solutions, what happens to innovation? If creativity, the force that arises from trying to solve problems, disappears, then how can AI generate solutions for challenges that don’t yet exist?

Even worse, if AI is trained using its own generated solutions, we risk entering a new paradigm: Endogamic Programming, a stagnant cycle where the knowledge base is fed only by its own outputs. Like stagnant water, this would lead to decay, limiting true progress.

Maybe I’m exaggerating, of course, but if we abandon the path of the Tao, what could go wrong?

PS: I have written and re-written this article several times until I felt it was what I wanted to express. I have use AI only to help me on the grammar and the clarity of the text. And I think that this is a legitimate use of this tool :-)

Avoiding complexity in software development

Fernando Fornieles — Thu, 15 Jan 2026 08:21:23 +0000

Keeping things simple is challenging. It’s easy to fall in over-engineering, implementing bright technical features just because we think they will be needed in the future or falling in the latest and coolest hype, applying it in our system only to realize later that it wasn’t the best solution for our problem.

“People often optimize for the problems they want and not necessarily for the problems they have.”
— Lars Rosenquist https://redis.com/blog/5-microservices-misconceptions/

No matter our level of experience, adding accidental complexity to a system is all too common. To mitigate it, we must exercise caution, share ideas, learn from colleagues, and adhere to principles that prioritize simplicity.

Fortunately, we benefit from the wisdom of those who came before us, and we can build a good set of principles based on their guidance.

Delay decisions whenever possible

“A good architecture maximizes the number of decisions NOT made.”
— Robert C. Martin (Clean Architecture)

I take this principe as a good advise to focus on relevant problems at each stage of a project rather than solving everything at once.

A good strategy to incrementally build a system can help us delay some decisions, be focused on the current problems and to reduce the cognitive load as well, which is one of the main causes that adds accidental complexity.

Avoid premature optimization

“Be wary of premature optimization. It’s always a good idea to make sure an algorithm really is a bottleneck before investing your precious time trying to improve it.”
— Andrew Hunt and David Thomas (The Pragmatic Programmer)

Writing performant code that sacrifices readability without clear evidence of performance issues is not only wasteful but also accumulates technical debt in the form of poor maintainability.

Improving the performance of clean code is always easier than making performant code readable. Optimize your code only when it is necessary.

Follow the YAGNI principle

“Always implement things when you actually need them, never when you just foresee that you need them.”
— Ron Jeffries

YAGNI, You Ain’t Gonna Need It, as simple as that.

Implementing certain features just because we think they will be needed in the future and will save us work is not a valid reason to do so. Think about the consequences. What if the anticipated features, implemented ‘just in case’ are never requested or prove unnecessary? We risk ending up with unnecessary code. Worse yet, what if the requested features are the opposite to what we expect? This would necessitate a complete refactor.

Following the YAGNI principle ensures we avoid unnecessary complexity, making the system more adaptable to evolving requirements.

There are many other useful principles that could be added, but doing so might introduce unnecessary complexity to this set ;-)

As someone wise once said:

“Those are my principles, and if you don’t like them…well, I have others.”
— Groucho Marx