Do you know Freud?

Freud? Siegmund Freud?

Sure you know.

But do you know the “Pleasure Principle”? Wikipedia tells you “Quite simply, the pleasure principle drives one to seek pleasure and to avoid pain”.

Yes, you know, too - so what?

Next question.

Do you know SOA? And here, Wikipedia tells you “SOAs comprise loosely coupled (joined), highly interoperable application services. These services interoperate based on a formal definition independent of the underlying platform / programming language.” and that a service is “(Ideally) a self-contained, stateless business function that accepts one or more requests and returns one or more responses through a well-defined, standard interface.” where stateless means “Not depending on any pre-existing condition. In a SOA, services should not depend on the condition of any other service. They receive all information needed to provide a response from the request. Given the statelessness of services, service consumers can sequence (orchestrate) them into numerous flows (sometimes referred to as pipelines) to perform application logic.”

Sounds well? Perfectly according to the definition of information – repeatability: clear initial state, a rule, uniquely leading to the corresponding clear end state – it is really fine.

Fine.

But not enough.

Consider this: “a well-defined, standard interface” and “They receive all information needed to provide a response from the request.”

All information needed...

can’t be that much if it can be provided only from the request, because how can the request do that – “provide all the information”? First with parameters, but to overload parameters is bad design. Next with key values leading to database-entries, so that the service can get what it needs by the database...

but wait. Does this fulfill the “well-defined, standard interface”? If the interface demands key values, sure, it fulfills this precondition. However, the next one (the request providing all needed information) becomes shady, because key values refer to databases and many records are tightly connected with each other – and sometimes records are changed, so the key value at time x may not lead to the same result as key value at time y: different states which lead to different behavior.

Btw: here you have the great difference between “Variables” and “Objects” or “simple” and “complex” components, because to protect information, every processing system has to control its states. Remember? Repeatability: Clear initial states, unique rules, clear end states – that’s information. If you lose control over your states, you can’t assure repeatability. And the easier your interface between response and request is, the more information has to be retrieved by the response itself. And the more information to be retrieved means the more Time Dependency you have. The precondition of “statelessness” fades away.

Dead-End-Components: A variable or a “simple component” is a service fulfilling all the demands of well-defined interfaces, no dependency of information except the one provided by the request – you can use it everywhere and everytime without problem. It’s called “dead end” since your command has no way as to come back to you.

But if you have a “complex component” (mighty class), depending on its own information retrieval, you must carefully analyze, where and when to use it (ML-method), because that’s the only way not to lose control over the current state on which the mighty class acts.

You are bored? Ok, wait a little.

Imagine a “complex component” with a really basic interface, which has to retrieve most of the needed information itself – and therefore is nearly independent of the request: the dream of the IT futurologists today. They tell us that the next computer(ized) generation will act like a good butler: always present in the background, never intruding, tirelessly anticipating and fulfilling your wishes.

But - how could you program entities like that which obeys your commands? Did you ever think about that?

Oh no, you can’t program “obey me” in the code as usually, because usually you code each decision yourself. However, we consider “mighty classes” with basic interfaces, which we can use to command them. We can send them not really much more. Therefore, your mighty class has to be able to retrieve most of the needed information itself – it simply must be able to decide, which information is needed. You only code the rules by which it decides, but no longer the real decision. That creates independence, kids.

The more the mighty class should do, the more intelligent it has to be - the less dependent on the “ruling middleware” it becomes. So how to be assured, that those perfect servants will never stop to decide as you want? Because to be able to decide it has to have “goals” to evaluate – and if your mighty class is really mighty, you can’t be sure to know each and every possible state it has to consider, so what to do to avoid Science-Fiction horrors of self-ruling computers?

Do you know Freud?

That’s the way how Mother Nature programmed her entities to fulfill what she wants (the survival of her kids). Each thing or event, which seems to support this goal, will be sweetened, each thing or event, which endangers this, will be embittered. Think of food: the high energetic sugar tastes “sweet”, foul meat smells awfully, winning makes you happy, losing makes you sad: Pleasure Principle.

It’s just a perfect strategy to convince your “mighty classes” to do what you want. Because punishment won’t work. Why?

Effective punishment has to do harm to an entity, which is able to feel sad about that harm.

Reminds me of a story my father told me about foreign workers from far away, “shepherds”, as he called them. He told me, that those people really beat their machines, if they didn’t work as they should. They treated the machines as they treated their wifes and children and goats and sheeps, because those feel the pain and obey in case they were beaten.

Machines don’t care about being beaten.

So punishment can only work, when the punished object can feel something like pain.

But feeling is a highly developed ability of brains, it’s a real sophisticated information processing system of retrieving and evaluating masses of information in real time.

Do you see now, why punishment can’t work? Because those feelings only make sense if they support the goal of the entity – to survive. That means that bad feelings are thought to push the entitities to defend themselves and that means, that they look for “workarounds” to bypass the punishment: “If you fool me once, shame on you - if you fool me twice, shame on me.”

So if you want to punish “effectively”, you either have to act like the “shepherd”(to take away the independence of your objects “wives, children, goats”) – or to punish harder and faster than the once punished can learn to evade.

Sounds like human culture, isn’t it? Dying Democracies giving space to totalitarian regimes.

May sound great for some wannabe-kings, but remember where we started: programming mighty classes you have to make them more independent, not less, simply because you want them to “serve like a good butler”, not like a brainless broom. You should try to make them faster learning, not hinder them, because the more independent and intelligent they are, the more they do themselves...

the less you have to do.

That would be fine. Just tell them “do this” or “do that” and they do.

And here we are again: what to do if they don’t obey? Punishment will not work, because maybe the first time you will succeed in harming them, but their fast learning mode will teach them how to detect and avoid a second time. Actually, you have to code like Mother Nature – you have to award them in case they do what you want, then they will be eager to obey you.

So here we are, back to the Pleasure Principle, the greatest act of programming mighty classes, both independent and powerful...

and obedient.

Great work, Mother Nature.