You can not make a reverse engineering of “why” somebody made a decision

Reverse engineering is a process of disassembling and analyzing a finished product to understand how it works, often with the goal of recreating or improving upon it. It is also commonly met in software development, when you want to know how a program works. To achieve understanding of existing code you need to use a special debugging tools and typically spend a lot of time. Once you understand it as a whole, you can do whatever you need… usually. What if you need to write further feature, but the code was written in a not standard way or there is a workaround, which you can not simply ignore? In such situation you would want to know why the code is made this way to safely finish your task. But the reverse engineering process might not answer the question “why”. Similar situations might take place in other engineering fields, like building construction, let me bring some examples. 1. Space Planning and Layout: The Observable: The kitchen is located on the north side of the house. The Difficulty in Reverse Engineering: Was it to maximize natural light in the living areas on the south? Was it due to plumbing constraints? Did the homeowner prefer a cooler kitchen? Was it simply the most logical flow based on the overall footprint of the house? Maybe the architect had a specific design philosophy about the placement of service areas. 2. Material Selection: The Observable: A specific type of brick was chosen for the facade. The Difficulty in Reverse Engineering: Was it solely based on cost? Aesthetics? Durability in the local climate? A personal preference of the architect? A long-standing relationship with a particular supplier offering a "good deal"? Perhaps the architect envisioned a certain texture or color that only this brick provided, even if alternatives existed. Maybe local material availability played a significant role that isn't explicitly documented. If a new person was assigned to building project and needs to make changes in the constructions or architecture, he will definitively need to understand why things has been designed certain way to proceed. Same applies to software engineering, let’s check up: 1. Choice of Programming Language: The Observable: The application is built using Python. The Difficulty in Reverse Engineering: Was it due to the team's existing expertise? The availability of specific libraries or frameworks? The perceived speed of development? Performance requirements for certain tasks? Perhaps the initial prototype was quickly built in Python, and the team decided to stick with it. Maybe the lead developer had a strong preference for Python's syntax and ecosystem. 2. Architectural Pattern Selection: The Observable: The software follows a microservices architecture. The Difficulty in Reverse Engineering: Was it chosen for scalability and independent deployments? To allow different teams to work on separate parts? Did the team anticipate a large and complex system from the outset? Perhaps a previous monolithic architecture proved difficult to maintain and evolve. Maybe the team wanted to experiment with a modern architectural style. 3. Use of a Specific Library or Framework Version: The Observable: The project uses version 3.2.1 of a particular library. The Difficulty in Reverse Engineering: Was this version chosen because it was the latest stable release at the time? Because it offered a specific feature that was required? Or perhaps because the team had prior experience with that exact version and felt comfortable with it? Maybe a newer version introduced breaking changes that the team wasn't ready to address. Without commit messages or project notes detailing the upgrade (or lack thereof), the exact reasoning is speculative. 4. Implementation Details of the Singleton Pattern: The Observable: A class is implemented as a Singleton. The Difficulty in Reverse Engineering: Was the Singleton pattern used to ensure a single instance for resource management? To provide a global point of access? Were the potential drawbacks of Singletons (like tight coupling and testability issues) fully considered? Were lazy initialization or thread-safe implementations specific requirements that influenced the chosen approach? 5. Implementation Details of a Specific Algorithm: The Observable: A particular sorting algorithm is implemented in a specific way. The Difficulty in Reverse Engineering: Was this implementation chosen for its time complexity? Its space complexity? Its readability? Did the developer optimize it for a specific use case or data distribution? Perhaps the developer simply remembered or copied this particular implementation without fully understanding the alternatives or the nuanced trade-offs. In software engineering, the "why" behind a code decision can be influenced by a multitude of factors: technical constraints, team skills, time pressures, business requirements, personal preferences of developers, evolving understanding of the problem, and even leg

May 1, 2025 - 21:31

You can not make a reverse engineering of “why” somebody made a decision

Reverse engineering is a process of disassembling and analyzing a finished product to understand how it works, often with the goal of recreating or improving upon it. It is also commonly met in software development, when you want to know how a program works.

To achieve understanding of existing code you need to use a special debugging tools and typically spend a lot of time. Once you understand it as a whole, you can do whatever you need… usually. What if you need to write further feature, but the code was written in a not standard way or there is a workaround, which you can not simply ignore? In such situation you would want to know why the code is made this way to safely finish your task. But the reverse engineering process might not answer the question “why”.

Similar situations might take place in other engineering fields, like building construction, let me bring some examples.

1. Space Planning and Layout:
The Observable: The kitchen is located on the north side of the house.
The Difficulty in Reverse Engineering: Was it to maximize natural light in the living areas on the south? Was it due to plumbing constraints? Did the homeowner prefer a cooler kitchen? Was it simply the most logical flow based on the overall footprint of the house? Maybe the architect had a specific design philosophy about the placement of service areas.

2. Material Selection:
The Observable: A specific type of brick was chosen for the facade.
The Difficulty in Reverse Engineering: Was it solely based on cost? Aesthetics? Durability in the local climate? A personal preference of the architect? A long-standing relationship with a particular supplier offering a "good deal"?
Perhaps the architect envisioned a certain texture or color that only this brick provided, even if alternatives existed. Maybe local material availability played a significant role that isn't explicitly documented.

If a new person was assigned to building project and needs to make changes in the constructions or architecture, he will definitively need to understand why things has been designed certain way to proceed.

Same applies to software engineering, let’s check up:

1. Choice of Programming Language:
The Observable: The application is built using Python.
The Difficulty in Reverse Engineering: Was it due to the team's existing expertise? The availability of specific libraries or frameworks? The perceived speed of development? Performance requirements for certain tasks? Perhaps the initial prototype was quickly built in Python, and the team decided to stick with it. Maybe the lead developer had a strong preference for Python's syntax and ecosystem.

2. Architectural Pattern Selection:
The Observable: The software follows a microservices architecture.
The Difficulty in Reverse Engineering: Was it chosen for scalability and independent deployments? To allow different teams to work on separate parts? Did the team anticipate a large and complex system from the outset? Perhaps a previous monolithic architecture proved difficult to maintain and evolve. Maybe the team wanted to experiment with a modern architectural style.

3. Use of a Specific Library or Framework Version:
The Observable: The project uses version 3.2.1 of a particular library.
The Difficulty in Reverse Engineering: Was this version chosen because it was the latest stable release at the time? Because it offered a specific feature that was required? Or perhaps because the team had prior experience with that exact version and felt comfortable with it? Maybe a newer version introduced breaking changes that the team wasn't ready to address. Without commit messages or project notes detailing the upgrade (or lack thereof), the exact reasoning is speculative.

4. Implementation Details of the Singleton Pattern:
The Observable: A class is implemented as a Singleton.
The Difficulty in Reverse Engineering: Was the Singleton pattern used to ensure a single instance for resource management? To provide a global point of access? Were the potential drawbacks of Singletons (like tight coupling and testability issues) fully considered? Were lazy initialization or thread-safe implementations specific requirements that influenced the chosen approach?

5. Implementation Details of a Specific Algorithm:
The Observable: A particular sorting algorithm is implemented in a specific way.
The Difficulty in Reverse Engineering: Was this implementation chosen for its time complexity? Its space complexity? Its readability? Did the developer optimize it for a specific use case or data distribution? Perhaps the developer simply remembered or copied this particular implementation without fully understanding the alternatives or the nuanced trade-offs.

In software engineering, the "why" behind a code decision can be influenced by a multitude of factors: technical constraints, team skills, time pressures, business requirements, personal preferences of developers, evolving understanding of the problem, and even legacy choices that were carried forward.

While code comments and documentation should ideally explain the reasoning, they are often incomplete or missing. This makes truly reverse engineering the original intent a challenging, if not impossible, task. We can analyze the code and its behavior, but the full story of the decisions that shaped it often remains within the minds of the developers who wrote it.