First lets do the most important thing. Let me explain. In this article reactive programming refers to responding immediately or as soon as possible to change requests to your application code base. Responsive programming however is viewed as a planned action based on individual or multiple change requests to your code based. From the get go Responsive seems to be the better way and frankly I agree but lets look into each method and see what are the pros and cons of each process. Often the correct approach is specific to the situation and either method should not be used blindly as a blanket approach.
Any adjustments to your code base can have unforeseen side effects.
An example of the two methods
To further expand on the idea lets look at an example. Lets look at the code below.
Lets say based on the code above the client runs in and tells you that you missing an important animal. So you now need to add a chicken to the animal list. What would you do?
The Reactive approach
The reactive approach is quick and simple we just add chicken to the animal list. And we are done.
This works. Lets check out the responsive approach.
The Responsive Approach
Even though the client requested one change we can foresee that the client might ask for more animals so how can we make this for efficient? How can you respond to this request in the future with minimal interaction with your code base. Why? Because every interaction with your code base can have unforeseen side effects.
Our updated code change is above. Now the get_animals_from_database function controls our source. This source can be anything it doesn’t have to be an actually database it can be a text file or an array.
Why is this better because we don’t have to touch the code base. Any adjustments to you code base can have unforeseen side effects.
So now you have a better understanding of the difference as outlined by me between the two styles of programming.
Reactive Programming
Reactive programming is the quick response to change request as outlined above. This can be quite beneficial to you. Lets look at the pros of programming reactively.
Pros of Reactive Programming
- Avoids having a long list of change requests
- Customer Satisfaction improves
- Conflicts based on changes are identified faster
- More work throughput
As you can see we have a good but short list of pros for reactive programming.
Cons of reactive Programming
- Breaking changes are almost guaranteed if not handle correctly
- Code base lacks structure due to constant unplanned updates (again if not handled correctly)
- Users might increase requests based on your fast response time (oh well)
- Unseen side effects can bring increases in change requests.
Responsive Programming
Responsive programming as outlined above is where you make changes to your code based on a planned schedule. What this means to me is that you can gather incoming change request review and analyze them and then decide how best to implement these changes and also how to avoid the reoccurrence of these issues.
Pros of Responsive Programming
- Slow changes to code is easier to handle and manage
- Getting to choose which change request to work on first (maybe). Prioritize.
- Handle updates using a holistic approach (birds-eye view of all the problems)
Cons of Responsive Programming
- Slow response time to change requests
- Less customer satisfaction due to the above
- Possibility of over engineering due to long deadlines
Which is better?
Its clear that the solution is neither one or the other. At times you may need to react to a change request. If something urgent comes up that you need to fix. You need to make that update. You should deal with it holistically but you need to fix it. Other times you can let your requests pile up (within reason) and you then knock them off one by one. You get to deal with a few at a time sometimes if possible
Conclusion
Its really up to you. I would prefer always the responsive approach. I think in every scenario it has the best results but this might not always be possible to achieve.
