What is the name of the phenomenon where a person abandons simplifying a complex system upon understanding the system? What is the name of the phenomenon where a person abandons simplifying a complex system upon understanding the system?

I provide examples of complex systems, so as not to get hung up on a specific domain.

Example 1

A new member of a software development team has to work with legacy, seemingly complicated code. Said person feels the need to simplify the code, and upon doing so, familiarises him/herself with the code. This is usually the point at which the new team member abandons the refactoring/rewrite. She thinks "OK, I understand it now. I can carry on with the actual task I set out to do".

Future new members of the software development team will now lose the benefit of this simplification, and will go through the same (arguably wasteful) learning process themselves.

The reason for the simplification could still be entirely valid (e.g. in a software context again: using domain types instead of primitive types;  to communicate intent more clearly).

Example 2

An electrician who has never been to a particular house is tasked with installing a three-way switch on the staircase. Said electrician sees the wiring and feels the need to rip it all out and start again. He/she starts making mental notes of the wires, their colours, which trip switches the wires are connected to, etc. After a while, the electrician understands the wiring, abandons the plan to rewire the entire house, and now simply installs the three-way switch.

Future electricians who visit the house will lose the benefit of the rewire (simplification) and will go through the same familiarisation process themselves.
The phenomenon may be explained like this :


The programmer was given the task to fix a bug on a complicated legacy code he does not understand.
The programmer forms a subgoal "Refactor the code", in order to achieve the above goal.
In the process of achieveing the subgoal "Refactor the code", he understands what needs to be done to fix the bug. So the refactoring is not a useful goal any more and it is abandoned.


So we have a primary goal of fixing the bug and a secondary goal, formed to serve the primary goal, to refactor the code. When the primary goal is achieved the secondary is no longer relevant.

To promote refactoring you must take actions so that the secondary goal of refactoring becomes also a primary goal, concurrently with other tasks like fixing a bug. For example you may give rewards to programmers that successfully refactor the code or you may change the culture of your team, so that refactoring is considered a social norm, etc.