[satanspastaroll]

Complexity can only ever be moved, never removed. This means complex problems are impossible to make easy, only a single part of a problem can be swayed with equal or worse cost to others.

This is best seen in abstractions; they make certain functions much easier to do on a routine basis, but they are less flexible than the functions they represent, and thus you end up with creating more and more abstractions, cases for them and at the end, end up with the same or more chaos than you had in the beginning.

This results in what I'd say futile work being done trying to fight it without even realising. You can't do something complex with less, or it wasn't that complex in the first place.

To make a truly malleable system, is to make a fractal, which is by definition impossible to solve. A problem(fractal) always requires a problem-area and accuracy in order to solve it, in that accuracy. There is _always_ an equal or worse tradeoff.

[Mikhail_Edoshin]

Abstractions in software are just that: we write a piece of code to do what we want to do and then we only supply parameters. Once we want to change what we are doing, we either have to go back to basics and come back with a new piece of code or somehow piggyback the existing code to fit the new scenario. The problem is that after we've written the first piece of code, we consider the thing solved. The first piece + parameters becomes the way of doing things and we are very reluctant to go back to basics again. So we start to pile up abstractions. But we don't have to. We can totally go back to basics and reduce the number of abstractions.

We cannot overcome the inherent complexity of the task (The Law of Requisite Variety) but it's not this complexity that bites us: it's the complexity of added abstractions.