Overcomplication in Programming: When Complexity Becomes a Problem

In software development, we often strive for elegant and well-structured solutions. However, there is a silent enemy that can make our code harder to understand and maintain: overcomplication. This phenomenon occurs when a solution is more complex than it needs to be, whether due to unnecessary code, excessive abstractions, or the use of inappropriate technologies for the problem at hand.

What is Overcomplication?

Overcomplication happens when code or architecture adds complexity without a real justification. This can range from excessive layers of abstraction to forgotten code snippets that continue executing unnecessary operations.

Common Examples of Overcomplication:

1. Unused Legacy Code – Functions or code snippets that are no longer needed but still execute, causing unexpected behavior.

2. Unnecessary Use of Design Patterns – Applying complex design patterns without necessity can make code harder to understand.

3. Excessive Abstraction – Creating multiple classes and interfaces just for the sake of it, making maintenance difficult.

4. Unnecessary Tech Stack – Using heavy frameworks or libraries to solve simple problems.

5. Verbose Code – Functions that do more than they should, making debugging more challenging.

A Real Case: When the Problem is in Forgotten Code

Recently, I spent an entire day debugging an issue reported by a user in an application I develop. After hours of analysis and testing, I discovered that the problem was caused by a leftover piece of code at the end of a function, which was unnecessarily redefining some information.

This code snippet was not only unnecessary but also interfered with the correct behavior of the application, causing confusion and wasting time debugging. This is a classic example of how excess code can be harmful.

How to Avoid Overcomplication?

If you want to avoid falling into the trap of overcomplication, follow these best practices:

✅ Follow the KISS principle (Keep It Simple, Stupid) – Keep the solution as simple as possible.  

✅ Avoid YAGNI (You Ain't Gonna Need It) – Don’t implement features you think you might need but have no real use for at the moment.  

✅ Review code regularly – Old code may contain obsolete parts that need to be removed.  

✅ Prioritize readability and maintainability – Clean, well-documented code is better than complex patterns without necessity.  

✅ Write automated tests – Tests can help identify inconsistencies and prevent the recurrence of issues caused by unnecessary code.  

Conclusion

Overcomplication may seem like a harmless issue, but it can cost time, effort, and even the reliability of a system. By focusing on simple and effective solutions, we can create cleaner, easier-to-maintain code that is less prone to errors.

Have you ever encountered a similar situation? Share your experience in the comments!

Static Recompilation: Porting games instead of emulating it!

Greetings!

Me and my friend often speak about ROMs emulation, decompiling and reverse engineering, and last night he did sent me an video about something new to me: the static recompilation.

Static recompilation is a way to recompile ROMs binaries into C code that can be compiled for any platform, so you can make ports, test different behaviours and more.

I'm still reading about this technology, there are some other tools like this on the web but I'm really excited to see an Nintendo 64 ROM being fully ported without a source code leak or something.
You can watch the video below, and I'm also leaving the GitHub project link at the end of this post!

Thanks for reading!

GitHub project: Mr-Wiseguy/N64Recomp

Why is it important to know the origins of a certain technology?

Introduction

I'm going to start this article with a phrase that I always say to all those who criticize or don't want to learn a language because of its difficulty:

Programming languages are not meant to please you or generate competition.
Each of them was born at a time when there was a specific need, and no other language was found to sufficiently meet that need.

I always had a huge prejudice against the Java language, because when I was starting out in the area, at the beginning of college, it was extremely difficult for someone who had barely had contact with codes before, so as soon as I could, I abandoned it and switched to Python and later I started learning about the web (HTML, JS, CSS, and a small beginning of PHP).
Finally, after some time I took a liking to PHP and specialized, today I work mainly with it and its frameworks, and as I have some interest (even if in the form of a hobby) in gamedev, I ended up picking it up to also learn a little C# and other languages that depend on compilation.

Turnaround

Anyway, years later, I was browsing a forum here and came across a comment talking about Java, and that's when I realized that the language looks a lot like what I'm already used to, and I felt the urge to give it a try. second chance for language.
I decided to go back to studying Java through a professor who I have extreme admiration for.
This professor has the habit of, whenever he starts a new course on something, making a point of explaining the history and origin of that something, and this made me see Java with completely different eyes than those who criticized the language so much in the beginning. of studies.

Purpose

To summarize my personal case in a few words: Java and I have a very strong characteristic in common:
A great interest in communications between devices and interoperability, or in a single more modern word: SmartHome!

I've always had a great love for the connected home, I'm currently transforming mine little by little, and learning more about how it works exactly and how I can learn to develop for this industry too, and the story of Java is basically this: It was born to make application interoperability possible, that is, the same compiled code could run on any platform as long as it has a JVM with JRE inside, and this could be anything, from a computer, to a car radio or a watch pulse.

Finishing

As I mentioned at the beginning of the post, the language came with a purpose to meet a demand that no other language at the time was capable of fulfilling in its time. It has changed a lot over time, but always carrying the same objective.
And that's why I believe that knowing the origins and history of a certain technology is crucial for your own development and learning with it, understanding the reasons why it exists, and how it will help you solve your problems.

Definitive Guide to Structuring Commits

Commit format

Each commit consists of three different elements, as below:

• Header - Required, this is basically the title of your commit
• Body - A more extensive description of the information you intend to convey with your commit
• Footer - If there is a ticket or issue, you can report it here

Both the Body and the Footer are optional, and as far as I can see, they are generally not used much.

Header

The header must maintain a predefined pattern, containing a type, a scope (only when applicable), and a title, and for faster and simpler reading and understanding, it must not exceed 50 characters.

{type}({scope}): {title}

Examples:
fix(login redirect): prevent redirect to external url
feat(middleware): refuse connections from other hosts on production
refactor(markdown viewer): prepared for future viewer package change
fix: serve HomeOffline and remove SWR fetch
fix(query): performance with large offset


These examples were selected from the list of commits in the official TabNews repository.

Did you notice how simple and objective they are? Any developer who has never even seen the repository before in their life, by reading these commits can already have a minimal idea of what the subject is about, and that is precisely the objective I want to achieve with this post!

Type

Here is the real inspiration responsible for my decision to write this post.

The type of the commit says practically everything about it, being able to inform whether this commit is related to a correction in a line of code, the addition of a new feature, improvements, among others.

The type must be one of those listed below:

• build: changes that affect the build system and/or external dependencies
• static: changes to the content of static files (data .css, .js, .json, images, among others...)
• ci: changes to CI* configuration files and scripts
• cd: changes to configuration files and scripts for CD*
• docs: changes to the wiki and/or application documentation
• feat: a new feature or resource
• fix: referring to an application bug fix
• perf: code change that improves application performance and does not change the way the user uses the application
• refactor: code refactoring, which does not fix a bug or change the way the user uses the application, it just rewrites the code in a better organized and structured way
• improve: some code change that improves the behavior of an existing resource
• style: changes that do not affect the meaning of the code (white space, formatting/identification, semicolons, among others...)
• test: adding new tests or correcting existing tests (normally it is not necessary to use fix in this second case)
• revert: revert to a previous commit

In addition to these, we have of course the famous merge, which is in a different structure pattern but is generated by GitHub itself and we understand its importance in the same way!

* Important observation: Today I do not have full knowledge of what CI (Continuous Delivery) and CD (Continuous Deployment) are about. So if anyone already has one or wants to make a post about it, let me know the post's URL in the comments and I'll be proud to learn about it and also attach it to the two items marked above!

About revert

If the commit reverts to a previous commit, it must begin with revert:, followed by the header of the reverted commit.

If the body is used, it must inform: This reverts the commit {commit hash}

About the scope

The scope, in short, is what exactly you are working on in that commit, for example middlware, a login screen, a specific resource, among others.

About the title

The title should contain a summarized and succinct description of the change, and the ideal is to follow the rules listed below:

• Use the imperative, and in the present tense and never in the past, for example: "change", "amendment", "implementation", and never "changed", "altered", "corrected", etc.
• Do not capitalize the first letter, keep everything lowercase except when it is a proper name, a system or language (for example MySQL, PHP), in these cases keep the standard name of what you are using. For example: replacing MySQL database integration with PostgreSQL
• Do not use a period (.)
• When it is necessary to refer to a specific location, function or field of the application, it is recommended to use the tag code referring to the platform being used, in the case of GitHub it is the three backticks (```)

Below is a complete example:

fix(controller): use cf-connecting-ip header to get client ip first

Body

A longer description for your commit can be provided right after the title, in a separate field, providing additional contextual information about your commit.

Break lines at least every 72 characters for better reading.

Use this description to explain "what" and "why" this change was made, rather than "how."

Baseboard

The footer may be provided below a blank line after the body.

You can use it to reference a ticket in Jira, a task in Asana or Perfex and other helpdesks, or even an issue on GitHub itself, as in the example below:

fixes issue #12

And why all this?

These are some possibilities and advantages that we gain when committing in an organized and succinct way:

• Automated creation of CHANGELOGs
• Automatically determines a semantic versioning increase based on the commit types used
• Communicate to other employees and interested parties the nature and reason for the change, in a clear and standardized way
• Trigger build and deploy processes
• Makes it easier for other people to contribute to your projects, allowing them to explore a more structured commit history with better traceability and understanding

I'm back!

Hello! Glad to see someone is reading my blog!

I'm starting to post here again and I hope you like the content.

Enjoy it!