Solving problems or symptoms?

The following quotes from the book "The One-Straw Revolution" caught my eye:

The more elaborate the countermeasures, the more complicated the problems become. ... When a decision is made to cope with the symptoms of a problem, it is generally assumed that the corrective measures will solve the problem itself. They seldom do. Engineers cannot seem to get this through their heads. These countermeasures are all based on too narrow a definition of what is wrong.

Although Masanobu Fukuoka's book is about agricultural systems, the concepts apply to systems in general.

With security, do we pile on additional layers of checking, detection, etc., or do we use a simpler and more secure technology to start with?

For reliability, do we implement elaborate distributed/redundant systems that check each other, or improve our testing of a single system so that it rarely fails?

When deployment mistakes are made, do we add more bureaucracy and red tape, or do we improve the process/tooling such that it is difficult to make the mistake in the first place?

When something is not working, do we add on layers of complexity to fix it, or try to simplify and identify the root cause?

One way to improve this is ask "why?" five times.