The Business Sense Behind Functional Programming

The Functional Programming (FP) paradigm has been enjoying a resurgence in developer circles for more than five years now. Its advocates however have faced difficulty making the case for FP when management sits across the table. Usually, the typical FP advocacy piece drowns the business advantages of FP in technical terms, and the audience tunes out. In this article, we strive to avoid this pitfall and ground the case for FP in the real world of profitability and risk.

We at Solita at positioned well to make the necessary distinctions: We boast great experience in FP, we count FP among our software best practices and we advocate for FP to our customers.

Quality

If your business offers a software product or service, you care about quality. The connection between quality and your bottom line needs no explanation. Let’s proceed then to the connection between the quality of a software product and an FP codebase. It’s a fact of life that code is faulty. All but the most rigorously written code contains faults and the number of faults per line of code is, on average, constant¹. The conclusion: more code, more faults. The FP solution to a problem is not only less code² compared to the typical alternatives but also less fault-prone on a per-line-of-code basis³. We may safely state: FP, higher quality.

Time To Market

Managers of most software products treat time-to-market (TTM) as priority #1. The time developers need to complete a feature is the primary driver behind TTM. Moreover, the effort required to tackle a software project scales superlinearly, i.e. if project A is twice the size of project B, it requires more than twice the code⁴. With less code to write for features and less code to test them, it is safe to state: FP, reduced TTM.

Strategy

Shrewd folks in the software business know that technology evolves very rapidly. They also know that being competitive is directly correlated to how well the business can keep up with these changes. One change that is here to stay is that getting better performance by buying faster processors is a thing of the past⁵. Steve Jobs, at the time, believed that the industry lacks the skills to address this crisis:

“The way the processor industry is going is to add more and more cores, but nobody knows how to program those things. I mean, two, yeah; four, not really; eight, forget it.” ⁶

These statements are a bit technical though, so let’s break them down. If you serve customers with a digital product, you are faced with a hard limit on how many customers you can serve per second. Any business which seeks to grow must have a strategy for pushing this limit upwards. Today, there is only one way to push that limit: write the software such that it scales. Such software though, is difficult to write in non-FP languages. The reason is that they encourage the sharing of computation state, an difficult thing to get right on a distributed system. By forbidding the sharing of state and by providing tools for mutating state explicitly, the FP paradigm has proven^{7 8 9} to be a much better fit for scalable software. It is, therefore, safe to state: FP, improved long-term growth.

Human factor

In the software world, managers bemoan the difficulty of hiring FP developers. This difficulty is an undeniable fact. The keen manager however, also recognizes that this difficulty is just another trade-off. Let’s take a closer look at the stakes: FP developers are aware of the comparative scarcity of FP jobs. FP developers are perfectly capable of delivering OO software. The typical FP developer foregoes safe, abundant, high-paying OO jobs so that they may develop in their favorite paradigm. Any manager who considers FP may therefore expect to run a highly motivated and highly performing team. Hardly the kind which the drive-by headhunter will cripple during the most critical phase of development. You are safe to infer: FP, tight and loyal team.

Myth-busting

FP adoption has been hindered by a number of misconceptions. Let’s set the record straight!

There are no libraries!

It depends on the language and the runtime. The most popular FP languages today run on the JVM and feature seamless Java interoperability. In other words: you may use any existing Java library you wish with them.

I don’t trust the runtime!

If the runtime is a concern, you have a wide selection of languages to choose from which are designed for battle-tested runtimes. Scala and Clojure run on the JVM, F# runs on the .NET CLR, Erlang and Elixir run on BEAM. All of these have proven their worth in production under extreme workloads^{10 11 12} and are actively maintained by large, reliable corporations.

I can’t reuse!

Whether it’s engineering skill or some trusted piece of in-house code, migrating to FP doesn’t mean throwing the baby out with the bathwater. You may pick a language that interoperates with the code or skill you want to reuse. Scala and Clojure interoperate with Java. F# interoperates with C#. ClojureScript interoperates with JavaScript and the list goes on.

It’s slow!

In today’s world of distributed computing, there is no excuse for complaining about performance without taking parallelism and scalability into account. If you develop performance-sensitive software for single-threaded execution, then FP might not be the right tool for you.

It’s only good for mathematicians and academics!

The many and varied success stories of FP adoption by industry disprove this. Be it networking¹³, messaging services¹⁴, finance¹⁵, insurance¹⁶ or web development¹⁷, FP languages are proving versatile and capable tools.

Conclusion

Functional Programming is a tool. A mature, stable and reliable tool with a track record reaching as far back as the ’80s. Nevertheless, not more than a tool and therefore only useful when applied to the right problem. From the business perspective, is safe to say that the current era of computing (i.e. distributed in a global scale) presents problems that are a good fit for this tool. Companies who succeed in putting FP teams together are on their way to building high-quality software and ensuring their long-term viability.