Reactive vs Responsive Programming – Which is Better

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.

Displaying an animal

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

Adding a Chicken for the client

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.

Pull the animals from a source

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

Photo by Pixabay on Pexels.com

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

Photo by Pixabay on Pexels.com

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?

Photo by Sora Shimazaki on Pexels.com

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s