Back to homepage

Signaling in programming

Posted on December 09, 2021

Doing decisions is hard. In order to make good decision having good inputs is crucial. In economy we have price signaling. Basicaly the higher the price is the more scarcer the product is. In order to do the right decision we have to do cost/benefit analysis everytime we buy something.

The problem arises when we remove the signal or we introduce a lot noise into the signal. Without the signal we can't have good output. This is on of the reasons why socialism is failing, it basicaly can't allocate the resources based on the prices.

But it's human nature to fight signals instead of reacting to them.

How is this relevant to software development?

There are signals all aroud our code. For example having to mock static method, the need to generate getters and setters, null chaining and many, many, many more.
They signal us that there is something wrong with our code if we run into them.

Unfortunately, humans do human stuff and instead of reacting to the signals the mainstream decided to remove them. We figured out how to mock basicaly anything, we invented lombok to generate the code, introduced optionals or null chaining operators. With those tools we pretend that the root of the problem is in the signal not in the actions that lead to the signal. And by ignoring those actions you will trap yourself in the dead end road of never ending technical debt.

That is the reason I am so sceptical for example about Kotlin or Microservices. Kotlin is awesome language, dont'get me wrong. But the problem I see is Java programmers migrating to Kotlin because it's easier to work with nulls and having data classes. For me this is signal avoiding. Same with microservvices. It's a great architecture. But most of the times I have seen a transition from monolith to microservices it was because the monolith components were coupled and its parts were highly unmodular. You can try blame monolith for that as much as you want but the problem is not the monolith but the way you have build it.
There are good reasons to use microservices, Kotlin, Lombok, Mocking and any other technology, but it must be other then fighting the problem signaling.