New feature or not?

I receive a lot of suggestions and feature requests for the MyGANTT software.

This makes me incredibly happy!

Your feedback is very important and helpful for the development of the program and the project itself.
Suggestions from users are extremely valuable. Criticism is also always very welcome because it allows me to think differently and understand things that I might have overlooked. It all contributes to improvement.
So I will never stop thanking you for this help.

Getting these contributions directly from users is fantastic! THANK YOU!!!

People often ask me why I haven’t implemented what they suggested.

I fix bugs as soon as possible. For feature requests, however, I need to give them careful thought before implementing them.

The reason is quite complex, and I want to share it with you so you can better understand the logic behind this project and the reasoning that guides its development.

The requests I receive are incredibly various and cover every field and every aspect of the software. All of them are useful and interesting, inspiring deep reflections that can even lead to other features.
Every single request is carefully evaluated. None are ever rejected. After careful consideration, I decide whether to implement it. Sometimes I even run a small test to evaluate it more accurately.

However, the feature isn’t always released in the software.

This happens for various reasons, but the main one is that I don’t want to complicate the software. I often have to fight against myself for this very reason. The software is designed to be simple, and that’s how it should stay. If I were to complicate it, I’d change the nature of the project, and I don’t want that to happen.

Ironically, adding features is technically easier than removing them. However, if the new feature complicates the interface or its use and understanding, effectively making it less simple and intuitive, the result would be disastrous. Instead of improving the software, it would make it worse.

Adding a feature involves many architectural decisions that go far beyond simply writing source code. In particular, we need to evaluate the impact the change has on the user interface (UI) and, consequently, on the user experience (UX). There are other factors to consider as well, but I don’t want to overcomplicate the explanation.

I hope this brief post has been helpful in giving you a better understanding of the work behind this software project.