I am currently working on a fairly extensive procedural animation system. That means there are a lot of different pieces which need to work together.
My procedurally animated characters need to step properly when walking, to correctly turn and look at things, sit down, stand up, reach for objects, pick those objects up and put them down again. All of which needs to happen in response to simple user directives.
The characters also need to be biomechanically reasonable. For example, when they stand and walk, their weight needs to be centered over their feet. And while all of that is going on, the characters should properly convey subtleties of mood, personality and intentionality through their shifting facial expressions and body language.
Like I said, lots of pieces. When I implemented my early prototype, I put in simple placeholders for some of those pieces — the algorithmic equivalent of rubber bands and chewing gum — and that was ok.
But now that the system is getting more sophisticated and I am demanding more of it, some of those simple placeholders are holding everything back. So in various parts of the system I need replace three or four lines of code that sort of worked by an entire carefully implemented subsystem which might take a hundred lines of code or more.
The replacement part serves the same purpose as the original. It just does it better and a lot more carefully.
When I see this sort of thing, it makes me think of any mature software system as a kind of fractal. At the most basic level software systems are pretty simple.
But then when you look further, you see that what seemed like a very simple thing (for example, in my case, how a character first places its foot when it starts to walk), might actually contain lots of complexity.
You don’t need to understand all the complexity to understand the system, and certainly not to use it. But without it being there under the hood, you just end up with rubber bands and chewing gum — a system that seems to work ok at first, but eventually just falls apart.