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.

  • $\begingroup$ It could be just the case of "If it isn't broken, don't fix it". However I can understand why simplifying the system is of benefit (to help those working on it in future to understand it) $\endgroup$ Commented May 24, 2017 at 16:46
  • $\begingroup$ @Chris, yes. I was thinking a small amount of hubris or Dunning-Kruger could set in initially, and then a small dose of humility shortly after learning the system, and after this period of discovery the urgency of the actual task sets in again. A chain of phenomena instead? $\endgroup$
    – opyate
    Commented May 26, 2017 at 7:55

1 Answer 1


The phenomenon may be explained like this :

  1. The programmer was given the task to fix a bug on a complicated legacy code he does not understand.
  2. The programmer forms a subgoal "Refactor the code", in order to achieve the above goal.
  3. 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.

  • $\begingroup$ Thanks for the contribution. I've provided another example of a system. Still hoping to know what the phenomenon is called. $\endgroup$
    – opyate
    Commented May 19, 2017 at 10:16
  • $\begingroup$ Not all psychological phenomenons are studied and named. Probably there is not any specific name for this phenomenon. What you can do is use general theories to understand what is described here. $\endgroup$ Commented May 24, 2017 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.