Escalation of Commitment
Recently, while reading “Thinking in Java” 4th Edition by Bruce Eckel, I encountered this term. Being unfamiliar with it, I looked it up on Wikipedia and couldn’t help but think about why the West is so powerful - they summarize and categorize the behavioral patterns and principles behind all phenomena. Combining this with my recent thoughts at work, I feel this concept has practical applications, so I’m marking it down here.
Concept
Escalation of commitment is a behavioral pattern that refers to when individuals or groups face increasingly negative outcomes, they tend to continue rationalizing existing decisions, actions, and investments rather than changing them.
The essence of this behavioral pattern lies in the sunk cost fallacy, which economists and behavioral scientists use to describe how when people realize their previous accumulated investments (sunk costs) have been wasted, they make irrational choices because they feel the already invested and unrecoverable costs would be “wasted.” For example, when consumers find out movie tickets are non-refundable, many force themselves to watch a movie they don’t want to see because they’re afraid of wasting the ticket money.
The above is excerpted from Wikipedia
My Thoughts at Work
In software development, part of the work isn’t just simply adding code. Sometimes we face situations where the original design was not okay and the existing code has problems. As a developer, being greedy for the so-called current correctness and speed, continuing with the original design, thereby worsening problems and enlarging pitfalls for future developers - this is wrong. For the project, it’s a mistake; for yourself, you lose an opportunity for improvement. After all, if you can create your own design that’s better than the previous one, the benefits this choice brings you are greater than just continuing with the problematic original design.
- I remember discussing this issue with colleagues and concluded that
developing and modifying programs requires being bold yet meticulous. - This doesn’t mean we should negate the past - we must have reverence for history and respect for predecessors. But at the same time, we should objectively evaluate the right and wrong of a design or piece of code, always consider the best solution, and ultimately make choices by combining various factors, rather than making excuses for ourselves. Both the process and results of this exploratory thinking are very important.
- Sometimes we often joke, “Look at this code of yours, it will be forever nailed to the pillar of shame in history.” This statement is a joke, but if it’s not a joke, its only purpose is to urge you to improve every day and always write the best program you can at the time.
