A Real-World Example

Once I was a participant in an interesting process (from a result evaluation perspective). We needed to solve two problems and had two solutions: one was principled (implementation from the beginning with consideration of solution requirements), while the second relied on an existing legacy codebase. Both solutions fundamentally improved the situation.

There were noticeably more high-profile (company-level) problems with the second solution, and more efforts to resolve them, which generally led to greater visibility. And, paradoxically, to greater recognition for the developer.

This experience reflects a pattern I’ve observed repeatedly in software development.

The Problem with Time-Blind Solutions

For a long time, I’ve been returning to the same thought. I’ve repeatedly encountered situations where architectural decisions in programming are made solely based on the principle that “the problem must be solved now,” without considering the temporal dimension of “what disadvantages might this solution have in the future.”

Interestingly, the consequences of this approach for the problem-solver seem exclusively positive:

• The problem is solved immediately, resulting in respect, recognition, and overall satisfaction
• The consequences of the solution emerge after an extended period – months or years – and there’s a high probability that these consequences won’t be connected to decisions made earlier
• Even if they are connected, who could have known? Perhaps no alternative solutions were offered, or if they were, something could have gone wrong with those too, and besides – we need to solve the new problem, preferably here and now

The Challenge of Time-Aware Solutions

If there is an alternative solution that takes the time factor into account, it’s probably more complex, both in implementation and argumentation. It’s difficult to add another dimension to a solution – time – and even harder to explain it (in my mind, this difficulty is similar to a person with good vision trying to explain certain visual information to someone who has been visually impaired since birth – information that simply doesn’t exist in the second person’s perception).

So the end result is:

• Stress during argumentation due to complexity and time constraints
• In case of success – a longer (obviously more extended) implementation
• The outcome is tainted by arguments like “this could have been solved much faster with the same result” (which may be true for the current state)
• The problem that doesn’t arise subsequently is obviously not noticed at all

This creates a perverse incentive structure where short-term thinking is rewarded while long-term planning often goes unrecognized – as illustrated in my opening example.