The Why Question and Arrow of Time

I have a mechanical engineer friend who is often called to diagnose and deal with problems at various sites across the country. He works for a recycling company which has plants in various locations. I am on the other hand a software engineer. We are both experienced folks who have some quarter a century experience in our pockets. We often have lunch together and exchange stories about engineering.

The business my friend works for is specialised to process scrap material obtained from breaking vehicles (cars, trucks etc) into pieces. They have sophisticated equipment to separate and sort scrap material according to their type (aluminum, steel, plastic) and weight.

Recently I have realised emergence of a remarkable pattern between his stories and mine. My friend mentioned he had been called on to diagnose a problem which was about a conveyor belt malfunction. Apparently the conveyor belt in question had excessive dirt cumulated on it. The foreman and workers rather than investigating the origins of the problem (why excessive dirt appeared at the first place), devise instead patch up solutions to clean up the dirt and this caused other structural problems on the belt.

In software engineering too when we have a tough problem, a crash without a stack trace, or an odd looking problem such as identical pointers appearing twice in a hash table thereby causing an infinite loop, some engineers cannot just wander off from their conventional comfort zones but instead remain stuck in the area where they first observed the problem. They automatically think an infinite loop is indicative of a problem right there. Similar to conveyor belt problem adjusting the hash algorithm to detect identical objects and handling the error at that point will not fix the originating problem. This approach will also make the algorithm needlessly complex and perform poorly.

Patch up fixes without understanding the root cause often result in expensive technical debt to cumulate which will cause more problems down the track.

Lateral thinking is a mindset, it is about asking the question ‘why’ and it is about the courage and ability to reverse the arrow of time.

The problem with the conveyor belt is not the dirt cumulated it is ‘why’ the dirt cumulated.

The problem with two identical pointers stored in a hash table is not an error with hash algorithm, it is ‘why’ the same object stored twice further back in history.

Lateral thinking is about going back in the history (time) and locality (belt’s location, program’s stack trace) and replaying cause and effect game in reverse direction.

Perhaps going back against the arrow of time is counter intuitive for most. Perhaps humans have evolved to go along with the arrow of time for pragmatically solving immediate problems with high survival value and only few have capability to rewind their thoughts back in history.

Could this be the fundamental reason why so many people find it hard to understand evolution. Reluctance, lack of resilience or inability to ask and track back the ‘why’ question.