I’ll start by showing you an image:

The numbers here show the number of lines added (marked green) and removed (marked red) from a specific codebase.

Correct, we removed over 95 000 lines of code.

Feel anxious yet?

Removal does not mean bad

There’s an old premonition that removing code from the codebase is a bad thing. It often manifests in stories of managers not wanting to pay programmers for removing the code. Or even a worse practice: assessing work performance by lines of code added.

Hopefully, most of these stories come from the 90s, and even then were cautionary tales depicting times of the past. The practice might have been widespread long long ago, but the tales are still with us today.

And it happens that some business people still feel anxiety about their developers not adding new features constantly (which is abnormal, by the way).

“Am I going to lose something?” they ask. “How might I report that to upper management?” they ask.

I’ve been involved recently in one particular project where my team removed four times the code we added. More importantly, we’ve maintained the schedule while improving the quality of the codebase by making it more reactive.

What is reactive programming?

If you’ve used any modern web application, such as Facebook, Twitter, or Gmail, you’ve already used reactive interfaces. Reactivity enables rich and interactive user experiences. Leading frontend technologies, such as React, Vue.js, or Angular, are reactive. Many mobile applications are written in a reactive fashion, using technologies like RxKotlin or Android LiveData.

A lightbulb analogy

The proper analogy would be a light switch and a lightbulb. When you close an electrical circuit by switching on the light switch, the light bulb responds by lighting up. In a way, you could say that the lightbulb reacts to the presence of current in the electrical circuit.

This is the most straightforward explanation of the reactive properties of a system anyone could imagine.

The physical phenomenon of the current flowing through the wire makes the whole circuit reactive. We do not need to notify the lightbulb further that the light switch changed its state, as it’s embedded in the electricity physics.

In the programming world, a similar way of thinking is represented in the so-called reactive programming paradigm. Though not present by default in most popular programming languages – like Java, JavaScript, Python, C++, it can be accomplished by using additional libraries.

It just happens so that it simplifies building rich user interfaces a lot. Here’s why:

• a reactive circuit has only one piece of information: whether the light switch is on. The lightbulb depends on that information.
• an ordinary object-oriented program keeps two separate pieces of information: whether the light switch is on and whether the lightbulb is on. A programmer needs to write the code that updates the second piece of information in accordance with the first one.

As you can see, the second scenario has a particular flaw – the program can be in an erroneous state when the light switch is on and the lightbulb is off. In the first case, it cannot happen.

Benefits of reactivity

The reactive approach reduces the amount of state (pieces of information kept in the program). Properly implemented, reactivity reduces the risk of error states in your application. 

Even better, it speeds up the development of the software product, as its operation becomes easier to understand by a programmer.

This is very useful particularly when building user interfaces with lots of fields, controls and dependencies between data. For such purposes reactive programming is usually the right choice.

It’s also a popular approach. Angular.js endorsed by Google, React endorsed by Facebook, Vue.js, and many others, all encompass reactive programming – coincidentally, these are the most frequently used frameworks for frontend development. The way the reactivity works in all these frameworks share enough to claim that there are no substantial differences between them.

Conclusion – Using the right tools

Now imagine changing the naïve object-oriented approach to properly implemented reactive programming in a large analytics codebase with a multitude of data flows.

As we discussed in the previous section, a lot of the code responsible for maintaining switches’ and lightbulbs’ states together was unnecessary when my team, piece by piece, introduced electrical wiring between parts of the application.

The result is here, and it’s something to be proud of:

Seeing the image for the second time now, it’s easier to imagine that the codebase in question might have lost some weight but gained in other essential areas:

• We’ve improved the quality of the codebase tremendously by making it more reactive, less error-prone, and easier to understand.
• We’ve increased the speed of development by now having fewer moving, error-prone parts to care about.
• We’ve future-proofed the application by reducing complexity introduced with new features.

While this example may be a bit extreme, giving proper thought to the architectural decisions going forward with any codebase, be it new or legacy, pays dividends.

Sometimes doing less is actually doing more!