Want a New Buzzword? Try 'Reactive Programming'

Every January we try to promote new technologies for the year ahead, and it seems that every year we end up inventing only buzzwords. This year, I'm trying a different approach: I'll propose a buzzword and hope to invent a technology trend with it. The buzzword is "reactive programming."

I came across this term last year, and I was immediately struck by its hype potential. If "reactive programming" is the future, then what is the present? The thesaurus says that the opposite of "reactive" is something like "impassive" or "indifferent," or maybe "unaware" or "unresponsive." How many line of business departments think these words are spot on with regard to their IT counterparts? And "reactive" sounds so... well... dynamic. It's a sure winner.

In our old model of impassive/indifferent/unresponsive software, we had applications that aligned with the steps associated in a given job function, like entering orders or receiving goods into inventory. This approach tends to harden not only IT processes but business processes. And as technology evolves over time, the hardened business processes end up constraining the new IT solutions, which means no progress or improvement in productivity is achieved.

Thus, "reactive programming." If you insist on niggling little details like the full meaning of a buzzword, reactive programming is a model of development that visualizes an application as a series of micro-elements (microservices, if you like) that run in response to specific events (messages). Each element is running asynchronously, which means it can be done in parallel with other stuff. As an application framework, reactive programming focuses on items of work that drive changes in condition, the consequence of which are other items of work. Think "If this changes, then do that," and you're close.

Unless you're a programmer, it's easy to fall asleep in a definition like this. Who cares, you might well ask? Underneath the lovely vague covers of reactive programming, however, there lurks the genesis of massive changes in how we use computing and communications.

Reactive programming promises relief from the traditional model of software-drives-worker. We've all played that game, following a series of steps that were imposed by an application while trying to relate each step to the business task we were actually trying to perform. With reactive programming, the goal is to let you do what the task demands, and fit your steps into a process of accumulating change until you reach a critical mass and actually update or commit something.

You can see that this approach has a major impact on application design. Instead of thinking of a sequence of steps, you think of atomic, unordered, perhaps concurrent steps that accumulate to the point where everything that needed to be done is done. The worker using a reactive application takes care of business in what seems an optimum way based on conditions, rather than trying to make work conform to a fixed sequence of steps.

Not only does this disrupt the notion of steps within an application, but it even threatens the notion of applications, at least as we've commonly viewed them. Workers are doing stuff. The stuff they do changes the state of the business, and the changes trigger business responses. This could easily eliminate the notion of an inventory system or a shipping system, replacing both with tasks like changing the inventory of an item. That change could trigger an order for more goods, put a hold on further order-taking at the retail level, and change stock-on-hand views.

Of course, the notion of applications is tied to the role that workers play. If you're in sales, you sell stuff and you use order-entry tools. Reactive programming says that you may be entering an order, but the order you enter will flow changes through the whole of the business. Who then do you call with a problem? How do you support a worker who sees each step they take as the tip of some great undefined sea-change of cascading icebergs?

The only possible answer is that the functional atoms that build reactive programs are themselves the target of support, and of collaboration. It's not a bad answer, since it focuses on what the worker's specific task is, but it does raise the question of who handles that flood of changes that happen behind the scenes. In the reactive world, you'd expect a problem with credit or inventory levels to generate an event. That would have to be routed back to the worker, who is now taking a role as a kind of reactive program element. Send Joe a message, because Joe is the target of the event called low-inventory.

You can still have sequences or chains of things in reactive programming; they represent what are effectively event source-to-receiver relationships that are mandatory because changes to the first thing are always going to have to be sent to the second thing for action. It's just that this chain now has to be explicitly created, it can't be implicit in the application because we really don't have a monolithic application anymore. Flows are the sum of information-driven changes.

So is collaboration. We'll have to work out how you can collaborate without the broad context that traditional workflows offered us. That may end up being the biggest challenge collaboration faces in 2018, but hey, think "reactive" and while you're working things out collaboration-wise, you'll at least be cool!

Follow Tom Nolle on Google+!
Tom Nolle on Google+