The proactive system
We are often well evaluate and praised t be proactive people, praised for doing one step further and trying to speed up work by assuming somethings when doing a task (maybe create a PowerPoint deck to present an idea, or going further and doing more than asked 🎉 often well perceived). BUT machines are not people and we expect things from machine commands, I don’t want my app proactively charging a customer that accessed an add-on in my app. Maybe we will help a couple of people and be a problem to all the curious users.
Problems with proactive systems
Computers are tools and tools are used to execute one job, when we have a system that does more than specified we start to loose the predictability/trust in the system because we don’t know what to expect. In the art of Unix programming, we have the Rule of Least Surprise (aka Principle of Least astonishment) that defends that we should defend as much as we can WYSIWYG - What you see is what you get - idea. If you’re using a calculator, the ’+’ sign should add, and nothing more, this clear interface, either graphical or through APIs, should be simple and reflect the expected behavior.
Proactive Systems in the other hand tries to do more than told, this is dangerous as the system takes decisions that hasn’t been specified by the client and also doesn’t guarantee that this is state is propagated so the client knows.
One example, imagine a payments API in which you have a due date for a given charge. The system receives a request to pay the charge due-date+1, and your system might think: This person might have forgotten to mark this as late, let me mark it as late and charge late fees for this. But indeed the client of the API wrongly set the payment date as due-date+1 when should have been due-date+0 . Now we have a charge with a wrong state, wrong charges because we tried to be proactive.
As a provider we should make ways available for clients of the system to be explicit in their actions so we have the assume the least when performing an action.
When should systems act proactively
In software some ways of being proactive are very good, like returning well written errors messages. When tying to pay a charge over its value instead of returning just Wrong payment HTTP 400 the system can return: Wrong payment HTTP 400 Current value: $500 . This simple modification will provide the necessary information for the system to know it did something wrong and also avoid another call to get the current value. In a system with high volume of requests this single query might be significant.
Also when designing by contracts, when preconditions to a given action are not met the system can instruct the user/API client how it should setup the entity for execute the wanted command.
Conclusion
So be proactive in your work but not in your systems. Systems are tools and need to be intuitive and clear in their purpose. Proactive systems might seem like a good thing at first but as soon as you need to revert this unexpected actions your system will become overly complex. So stick with simple interfaces and clear contracts! Save yourself from more work! And be proactive without making decisions!